Last post Nov 27, 2009 04:45 AM by abhitalks
Nov 11, 2008 09:10 AM|jparlato|LINK
I wanted to provide my opinion on the MVC pattern usage, to generate any discussion and/or guidance that might be gained from my study of this pattern.
For some time now I’ve been reading and listening to the pundits of the Model View Controller Pattern for ASP.NET; also known as WebMVC pattern. I’ve built some prototypes and used
the pattern via exercises to gain knowledge of this new pattern soon to be delivered in VS 4.0.
As this pattern is now becoming more fully defined and is soon to become a standard pattern supported in ASP.NET vs 4.0, I thought I would provide you with my opinion as to whether
we should or should not adopt this pattern in web application development here at GSOC.
My view is guided by what, if any benefits does it yield and what, if any downside is there.
On the positive side the pattern offers a clean separation of view, logic, and data tiers. There is no doubt that this is accomplished because that is the main objective of MVC.
However, the logic or controller components are still trapped in the web domain and are not re-usable outside of that domain. They depend on global.asax settings and run under iis http. Therefore, there is no re-usability of this component outside of the
web site… You could not for instance, make use of that logic in a winforms application or service.
Moreover, the ability to cleanly separate presentation, business logic, and data access is available today without the MVC pattern. Using WCF and multi-tiered programming – we have
the ability to provide the same separation and we have no less ability to share these components (especially via WCF) with non-web application such as services, win-forms, and even non-.Net platforms. In fact, with WCF we can globally share business and
data logic without restriction of MVC’s ties to iss /http: platform. Hence, I’m not sure the separation of model, view, controller duties, provided by MVC, buys us much here.
A down side issue for me, is that the view components – in the MVC Pattern – revert to the classic asp method of coding, where <%= for each ….. style coding is mixed into the html
web page. This is very hard for me to buy into.
The .net code behind / server code model is much cleaner and much more understandable that the classic asp approach to coding and I would not want to see the mixing again of html
and c# or vb code as the way of the future.
Microsoft itself has stated that MVC is an optional pattern, use it if you like it or don’t if you don’t feel comfortable with it. The capabilities of MVC are available without MVC
and for me, the choice is that we should not pursue this coding pattern. There is very little, if anything to gain, and the negative use of html/mixed with application code is less than attractive to me. The more valuable approach to XXX, in my opinion,
is to pursue and take advantage of multi-tiered programming, WCF, and the code behind asp.net techniques.
Because the separation of the model, view, controller components doesn’t provide out of web usage – it falls short in my opinion of the goal of writing application and data logic
once and re-using in anywhere you need it. To me, WCF is a better answer to this need and it does not fall short. For instance, the .net prototype of the new GDP that I wrote and is now on hold, is using multi-tiered programming and WCF. Its business and
data tiers have already been proven in testing to allow both windows forms, service, and web apps to access these tiers and access complex objects from that pattern. This, is the better choice in my opinion.
I would not recommend the use of MVC pattern, unless there is some circumstance – unforeseen to me at this time – where it would be mandated and would provide some otherwise unattainable
Nov 11, 2008 12:07 PM|HeartattacK|LINK
Nov 11, 2008 02:50 PM|Sgro|LINK
To the OP, your post COULD be interesting if something did not exist, but it does. This something are "Web Standards"
I challenge you making a xhtml compliant, wcag-aaa compliant, accessible and usable web site using webforms without going crazy.
I challenge you using standard unobtrousive JS without going crazy.
I challenge you having a full webforms site work fine with JS disabled. You simply can't if you use some asp:controls because they depend on JS. And since a true web site/application MUST be 100% usable with no JS or CSS support, a great part of the asp:controls
I challenge you BEING a professional web developer using webforms. Webforms is a paradigm to allow winforms programmers to approach the web without knowing it. That's why it's something for amateurs.
Real web developers KNOW WHAT THEY ARE DOING, and therefore use tools that allow them to follow the rules. Those tools are Ruby on Rails, Microsoft Asp.NET MVC, MonoRail and some others, but NOT webforms.
So much for your "unforseen reasons". You are not a web developer, no wonder you can't understand. People pretending to be web developers without even knowing the basics, are a real insult to OUR profession.
Sorry if I sound rude but I am sick of hearing total amateurs sentencing on a profession that they don't even know. Go to Hulk Hogan and teach him how to wrestle, I'd be amused to see his reaction.
Nov 11, 2008 03:24 PM|ShaneBauer|LINK
However, the logic or controller components are still trapped in the web domain and are not re-usable outside of that domain. They depend on global.asax settings and run under iis http. Therefore, there is no re-usability
of this component outside of the web site… You could not for instance, make use of that logic in a winforms application or service.
I would argue that you're not trying to reuse your controllers. Your controllers should be simple, and to the point. Your model/domain should be thick. If you have complicated controllers that need to be reused, then you probably have something wrong.
A down side issue for me, is that the view components – in the MVC Pattern – revert to the classic asp method of coding, where <%= for each ….. style coding is mixed into the html web page. This is very hard for me to buy
There, IMO, is nothing wrong with that style of coding. The main issue with ASP was the mixing of business logic with presentation logic. You should only have presentation logic within your view. Even then, you can eliminate a lot of the looping and structure
controls with helper methods.
The .net code behind / server code model is much cleaner and much more understandable that the classic asp approach to coding
I completely disagree. The code behind model is much more complicated. Events, controls, life cycle. Lots of stuff. Have you tried testing those pages? The code-behind model is too complicated.
and I would not want to see the mixing again of html and c# or vb code as the way of the future.
As a developer, you need to learn not to mix logic into your views. Being a better developer is the way of the future. If there is complicated logic in your view, then you have a serious concern outside of the framework.
There is very little, if anything to gain, and the negative use of html/mixed with application code is less than attractive to me. The more valuable approach to XXX, in my opinion, is to pursue and take advantage of multi-tiered
programming, WCF, and the code behind asp.net techniques.
Again, you should not have application code in your view. Sure, you could do it. But you know how much application code and presentation code
could be mixed up in the code-behind model. A ton. In fact, I've rarely been to a company that didn't have an application coded in such a way.
Futher, testability is one thing you gain right away.
Nov 11, 2008 03:56 PM|dsa1971|LINK
I can certainly see the benefits of MVC and many other tools but to say that webforms is only for amateurs is utter nonsense and really only serves to discredit you. While I agree that in a perfect world all websites would be usable with or without JS
or CSS not all websites live in the public facing world. I have worked on many internal websites developed using webforms as well using the MVC pattern. I would argue that real developers know their requirements and know their audience and can determine
the best tool for the job that meets the requirements and can get the job done in the least amount of time. Some places that's MVC, some places it's webforms, etc. Where I work, webforms does the job quite well.
Nov 11, 2008 06:16 PM|jparlato|LINK
You do sound rude, but thats ok... I appreciate your taking the time to respond. Have great day.
Nov 11, 2008 06:23 PM|jparlato|LINK
Thanks, you helped make the point I may not have made that well. I too think MVC is a great model. I've had higher expections though, in that I do think the controller logic should be re-usable from any platform. I don't say that my expection was the
only way to think about it, but if I'm going to trade in Winforms for simply the ability to force clean seperation - I already have three tiered applications, using WCF and a business layer that is re-usable from windows services, and othe applications - as
it communicates with wcf. Am I incorrect in my thinking that the controller contains this business logic? If it does, then it is not re-usable... I'd be happy to hear someone explain where I'm wrong. I'm not an MVC expert, but I'm trying to see, in my environment,
where it gives me value that I don't have.
Nov 11, 2008 06:25 PM|jparlato|LINK
Thanks for taking time to give me this feed back. I have benefitted from you detailed reply and I will continue to listen and evalute with the benefit of your comments.
Nov 11, 2008 06:33 PM|ShaneBauer|LINK
Am I incorrect in my thinking that the controller contains this business logic? If it does, then it is not re-usable... I'd be happy to hear someone explain where I'm wrong. I'm not an MVC expert, but I'm trying to see, in my environment, where it gives me
value that I don't have.
No, the controller should not contain the business logic. A controller should not make business decisions. The controllers are only there to link your domain/model/business logic to your view. It helps inform the view of your model. It's basically the bridge
that connects the two.
Thanks for taking time to give me this feed back. I have benefitted from you detailed reply and I will continue to listen and evalute with the benefit of your comments.
You're welcome. Glad I could help.
Nov 11, 2008 09:43 PM|brianjlowry|LINK
ViewState is embarrassing. That's all that needs to be said.
Nov 11, 2008 10:27 PM|zsuzen|LINK
You should not compare MVC with WCF but WebForms. MVC is strictly a 'user interface' pattern. I think the confusion is there because of the evolution we are seeing in rich web clients (AJAX and so on). I.e. I fail to see how you can use WCF and WebForms
and come up with a 'better' architecture.
Here is how I see it, if it helps:
WebForms is a great component model. It enables tooling, ease of development and abstracts lower layer HTTP/Web details. However, when it comes to the details of the 'Web User Interfaces' it becomes exponentially harder to develop, because of the complexity
required for abstraction. And the main reason for this complexity is state management. HTTP is stateless by definition but WebForms has to compensate for that.
MVC, on the other hand, does the opposite. There isn't much abstraction on top of HTTP/HTML and so on. Instead of trying to hide shortcomings of underlying protocols and languages, MVC fits in with their principles. That's why you see some 'code constructs'
in aspx (they are generating HTML after all not hiding it) pages and controllers maps to 'HTTP Requests' one to one, for example.
One last thing about using WCF. I think MVC can use WCF behind the model, to pull data or run 'business logic' (BTW, I don't believe you can 'truly' encapsulate business logic in one layer, but that's another discussion). However, I admit that MVC controllers
and WCF restful data APIs are overlapping to a certain degree, which sometimes results in misuse of the technology and at the same time opening opportunities for experiments and evolution.
Nov 12, 2008 12:04 AM|zsuzen|LINK
Couple of other points:
There is no one model of development or achitecture for all the applications. Multi-tiered programming might be overkill for some of the web applications. This may exclude WCF from the list of frameworks to be used. However, MVC v WebForms would still be
a question during 'architectural' decision making.
My second point is about the 'software development process'. Kind of related to the first one, personal preferences or the application requirements will affect the SDP. If one chooses to work with an iterative, test driven model, MVC will be very valuable
there. Because the MVC framework is developed testing in mind, it supports certain testing concepts (for example object mocking) by providing extensive set of 'Interfaces' for almost all of its APIs (which I think helps with 'prefer Aggregation over Inheritance'
suggestion). So if a team is developing with TDD methods then it will be easier to use MVC instead of WebForms.
Nov 12, 2008 12:36 AM|shapper|LINK
Maybe MVC has its downsides ... I agree that the sepparation between Controllers and Business logic is not straight forward ...
But one thing is sure: try to create a web application that follows Web Standards with Web Forms ...
Believe me, I created many custom controls to acchieve that ... it takes a lot of your time.
MVC makes that much easier along with other things like using JQuery, Ajax ...
Basically, in my opinion MVC gives you more control ... now if we use that control in a right way that's another discussion ...
... or if ASP.NET MVC should change some features ... that's one more discussion.
But as I see it, more control over what you are developing it always good.
That's just my opinion,
Nov 12, 2008 05:37 PM|levous|LINK
I DO recomment MVC and here is why!
When developing WebForms, I have to be aware of a complicated page lifecycle. This is a
feature that provides a lot of capability but also is a model the encourages poor design. For example,
a button click is something that is wired up for me using ViewState. When the page loads,
and it is a page, somewhere halfway down the tracks the event is raised and my code is given control.
Quite a bit has already happened: the control structure has been parsed, viewstate consumed, etc. If everyone on the team, over time, have been good little programmers and they've
encapsulated their logic in objects, it shouldn't be too hard to follow. That is usually not the case.
Ever had to scroll for days on someone's Page_Load? Then, when things don't work right because of some order of operations issue, they start moving everything to Page_PreRender. Yuck. Inside these automatic event handlers is a blatant
mix of data access, business logic and presentation. Sure, the presentation is an object representation of html but its still presentation. Have you noticed those long ids that Asp.Net adds to server controls? Nice. A psuedo complicated
page will become very difficult to follow over time. Refactoring that page is a huge challenge because it is not easy to test a page. What if I want to use a
carefully designed information architecture for my url patterns? SEO anyone? In web forms, a url is a page and a page is a file on disk. You can use rewriting technologies but the page then gets confused about where it is. Its going to be
a challenge just keeping things wiring correctly, much less abstracting business rules. Why should the presentation code care about where it sits on disk? If url means path to a page, which it used to, then everything is fine. If, however, your url is a
composite representation of various parameters used to retrieve or manipulate data, then that page should not be the hander of the request but merely the delegate for packaging the response. IMHO
MVC, in contrast, gives the request straight to you, in the controller, before any presentation has been considered. The request has been packaged up for you so that you can work with parameters and prepare your model for the user. When it comes
time to display, a single controller can use the same data and business logic (reuse) to present any number of views. Ajax request? ooo, I'll render the stripped down, ajax view. Your an admin? you get the regular view with the admin master. The controller
places the finalized (hopefully) data into the ViewData vehicle and then hands the whole thing to the view of its choosing. Business logic should now be done. Its testable, too! So you outsourced a feature and they delivered a monolythic, scroll forever
controller action? Write a few assertion tests and then start refactoring things. You don't have to render a single page, record a single fragile scripted web test or even run a web server. You can work, test and validate your rules without looking at a
web page. In the mean time, your html is in a completely separate file where an html UI guru is jquerying it till he's blue in the face.
There are numerous advantages to receiving the request at a class method rather than a page, if that represents value to you. Its basically making Http Modules and Handlers and first class component of your site architecture, implicitly, without any of
the complexity and then abandoning the notion of post back and view state. Its the act of embracing the web's stateless model rather than trying to fake it out.
There are certainly times when tossing a webform page out in your directory structure and binding it to a table is going to be the best solution. There's hardly a faster developer experience than filling a datagrid. However, at some point, you may
need to modify things in meaningful ways and MVC provides a consistent, simplified, object oriented approach to delivering website content from a dynamic engine. Like anything,
it can be applied well or not so well.
There is nothing wrong with using WebForms and you might very well like it better. That's fine. It doesn't have to be a religious debate. Personally, I was using Monorail a few years ago because I was attracted to the structure and
design approach. It was a hack around asp.net. It worked great, though. Asp.Net MVC is Microsoft's response to an ever growing community outside of Microsoft who have embraced the pattern and found it encourages a better design. As has been stated before,
its just another tool, not a replacement. In fact, you can mix MVC with WebForms with whatever!
I know plenty of good developers who love Asp.Net webforms. They love to drop server controls in the designer and bind their data using datasources. They appreciate the ability to set the border as a property on an object and handle the click of a button
on the server as if it were a windows forms application. There will be those folks who get very excited about using Silverlite to produce an exceptional graphics-centric UI. Some of us, however, are stuck in html and we have very strict standards to adhere
to. Those standards change, as well. In order to be nimble and able to accomplish very specific things in html as the result of a web request, MVC is an awesome, proven design pattern.
Nov 17, 2008 01:13 AM|TATWORTH|LINK
At the risk of being flamed by the community, I also do not recommend MVC. I have such techniques used yet without the promised testability being realised.
I have seen conventional webforms achieve 100% XHTML, 100% Business Requirement Compliance and 100% on-time. If you have produced a better mousetrap in MVC then eventually the world will beat a path to your door, however the orginator of this thread and
myself remain to be convinced of the benefits of MVC.
Nov 17, 2008 01:42 AM|pure.krome|LINK
Lolzor @ threadzor.
To the OP and Tatworth -> who cares? Stick with your WebForms and rejoice in what they offer. The everyone else, rejoice in web development ... the way it's ment to be.
For those that don't like MVC - no probs at all. ... just don't come over here and start dissing it (such as the subject of this post). Instead, try and be more diplomatic in your questions (eg. i'm
still confused to how this MVC thingy is an improvement over WebForms ... IF it is an improvement).
WebForms and MVC are religious wars just like C# vs VB.NET.
there's plenty of ways to skin a cat - that's the beauty of this .. options for everyone.
enjoy your webforms. enjoy your asp.net mvc.
Nov 17, 2008 03:51 AM|mvcian|LINK
I apriciate all members for starting such a nice discussion.But what about the response time of an application developed with MVC or Web Forms ? What about Post Back vs REST ?
Nov 17, 2008 04:39 AM|pure.krome|LINK
The response time should be nearly the same ... they both share the same modules under the hood -> eg. caching, membership, profiles, authentication, etc... it's all the same code. Where it differs is how the HTTP Request method is handled. Depending on
what your using, you either goto the mvc handler or the web forms handler. IMO, MVC should be faster because there's NEVER any viewstate being passed across and you can unwire all the event based handlers which means less code to get called .. but all this
is adds up to hardly anything .. it's all so quick.
Now .. REST and Post Back are two totally seperate things .. so don't get confused by them. When you 'post back', you're actually sending a stock standard HTTP Request to the web server. The tricky thing (or painful .. depending on your point of view) is
that if you look in the data of the post back, there's all this viewstate stuff and other magic data... which tells the web form engine that this is a 'postback' .. .. which just flags the request as a PostBack (eg. this.Page.IsPostback == true or false) ..
allowing the programmer to do whatever they need to do differently, under a postback scenario. It's still a stock, standard HTTP request .. no different to any other browser chatting to any other web site.
Ok .. so what about REST? REST is just a way to show the webpage url. Techincally, it's not a 'page' at all .. but a resource. so images, 'pages', etc.. are all resources. And it's displayed in a format that is really easy for us humans and computers to
read/understand. (eg. http://www.mysite.com/article/1) There's also some other special sauce with REST .. about
how you are talking to a server (called HTTP Verbs .. such as GET/POST/PUT .. etc) .. but that will just confuse you.
You cave RESTful urls for both WebForms and MVC with the latest version of the ASP.NET framework (3.5 and onwards) because that magic has been cooked and baked into the core framework.
So for myself, i'm an MVC fan boi because .. to me ... i find it's more efficient because i'm in
more control of the entire application life cycle (read: from the time the webserver gets the Request Data. .. right up until i tell it the last piece of Response Data) .. mostly the later lart of the cycle .. such as the view stuff. Don't forget testing,
blah blah blah .. what they all said above.
Nov 17, 2008 07:40 AM|mvcian|LINK
I m thankfull to you for writing the replay. I m also pro mvc, but I love critics. So I appriciate all members for their views.
Nov 17, 2008 08:38 AM|TATWORTH|LINK
> I'm thankfull to you for writing the replay. I'm also pro mvc, but I love critics. So I appriciate all members for their views.
Hopefully we can disagree without being disagreeable!
Nov 17, 2008 09:16 AM|shiju|LINK
Both WebForms and MVC are just options. if you feel WebForm is more comfortable, use WebForm and use MVC if it is right for you.
Nov 18, 2009 12:37 PM|rgalante|LINK
Here is my experience with a specific application. I am trying to decide which development platform to use (web forms or mvc). Here are the requirements.
1. Maintain Existing Functionality of Classic ASP application
2. Use Existing Database Objects
3. Add Localization and Globalization
4. Use metadata to define data object bindings between the forms and the database. Cannot use Linq to SQL or Linq to Entities to build the metadata or the database interface.
5. Have one form or view that enables all database objects to be created, displayed, and updated. That means I have one controller and one view for all database objects that require persistence. This view uses the metadata to render the form's html controls
dynamically. The metadata defines the db persistence bindings as well. We have to do this or we will have a hundred or more controllers and views.
6. Build three tiered menus dynamically using database configuration that is based on roles. These menus have to be updatable and dynamic in case we add features in the future.
7. Support standard ASP.Net authentication and authorization.
Problems with MVC:
1. I have to use a querystring to define the selected menu options because the routing is short-circuited by the generic controller/view requirement. This is ok because SEO is just not that important in my application.
2. In order to maintain existing functionality I have to use existing web forms controls (spellchecker, spreadsheets, etc) because similar controls do not exist in MVC. If I do this, and I can, then I have ViewState and code behind, defeating another design
goal of MVC.
3. Unit testing adds significant cost to the effort. Unit testing is great, but I don't have the budget for it. I'd love to do this though.
4. Ajax postbacks that update a div tag on the page and that generate an exception display the error page inside the div tag instead of loading the complete error page. I can code myself out of this issue, and it would be an issue in other platforms, but
I don't have this issue with web forms.
5. No, multi-lingual, client-based, validation controls. In fact, I have to develop two solutions in order to validate a form on the server side and the client side. Remember, my solution has to be localized.
that updates the window's location for example). This is important for the login page and the commerce areas.
So I feel like I'm trying to squeeze my application into this design pattern. Is anyone else having these kinds of issues?
Nov 18, 2009 12:57 PM|gerrylowry|LINK
the logic or controller components are still trapped in the web domain and are not re-usable outside of that domain. They depend on global.asax settings and run under iis http. Therefore, there is no re-usability of this component
outside of the web site… You could not for instance, make use of that logic in a winforms application or service.
(a) I am using ASP.NET MVC applications for both Internet and Intranet
where this is appropriate. One application for two domains.
(b) assuming by the "logic component" you mean the Model, much of it is reusable for desktop applications assuming that the developer is building her/his black boxes with proper consideration.
Nov 18, 2009 04:06 PM|ali62b|LINK
Equation is much simpler than we think dudes! those folks programming in both win and web prefer web form because of drag and drops , evens , and hiding the http and its stateless nature in web from but those folks focusing on web developing (including me)
not only hate viewstates and code behind and dealing with events but also they waiting for a framework like ruby on rails coming out from Microsoft for a long long time ago because they want more control around their HTML and don’t want to look for the
magic events in a datagrid to show some colorful data in their rows!
Nov 18, 2009 04:27 PM|gerrylowry|LINK
... folks programming in both win and web prefer web form
Likely an over generalization. I can work in both. I prefer ASP.NET MVC.
Nov 27, 2009 04:45 AM|abhitalks|LINK
ViewState, ControlState, MyState, YourState... are not as important as the "State-of-your-mind".
You can write a complete webforms application without using these "states" at all. Just disable viewstate and go run. Write a good DAL and BLL and top it up with clean aspx with only presentation logic. Use as much of HTML controls as you can and stay away
What do you have now with you, is nothing but an MVC pattern developed out of webforms (of course sans REST but you can have that too if you wish to work more). Accessibility and graceful degradation is another topic another day. MVC is a pattern. It is
a state-of-mind. An approach. Nothing more. MS ASP.Net MVC is a framework which just makes this work easier. And cleaner. A tool.
it contributed to the web we know of today."
Similarly, go stick to webforms if you feel comfortable with it. You can still do wonders with it. Use MVC vice-versa. It all depends on what you want to achieve and how. They are all just tools. You are the craftsmen. Right tool for right hands. Yet...
A razor in a monkey's hand could be dangerous. Or who knows, it might not be!