I've noticed a lot of talk about asp.net MVC lately, but I haven't come across a clear or compelling description of when, where or why I would want to use it over WebForms.
Let's say I wanted to build a small web application that allows a person to advertise some items online. The website will have 4 use cases:
Search adverts
View listings
View item
Place an advert
Let's assume:
I'm not particularly interested in unit testing my controller. The page will either render the list of items correctly, or it won't.
I am interested in more control over the HTML markup.
I'm not interested in using the latest buzz technology just for the sake of it.
I am interested in using the tool that is best suited to the job in terms of productivity, performance, maintainability & simplicity of the end solution.
I don't want to have to work around a bunch of nuances to get something simple to work.
So, my questions are thus:
What are the fundamental differences between the two models?
In which scenario is one better than the other?
What are the gotchas with asp.net MVC (I'm aware of the gotchas with WebForms)
For our sample app, what would I gain by using asp.net MVC instead of WebForms?
For our sample app, what would I lose by using asp.net MVC instead of WebForms?
Is it feasible to mix and match models within the same small application?
Thanks to anyone who spends the time to contribute an answer.
What are the fundamental differences between the two models?
WebForms try to mimic WinForms development by allowing you to reuse lots of pre-made controls, and by faking web application state via the hidden _VIEWSTATE mechanism.
MVC is a pattern designed to help you separate your data (Model), business logic (Controller) and presentation (View). It adheres more to the true nature of the web : RESTful URLs, stateless.
In which scenario is one better than the other?
In my opinion, for an intranet application making heavy usage of controls, WebForms can be useful at reducing development time, because thanks to the designer you can create your UI very quickly and let the framework manage the app's state automatically.
For any other project, especially a public website, even a small one, I think MVC is the way to go.
What are the gotchas with asp.net MVC (I'm aware of the gotchas with
WebForms)
I'd say there is some learning curve to fully understand the MVC pattern and its power. Also, since the framework is still in BETA you can expect the API to experience some minor changes before release.
Since JavaScript is not hidden from you in MVC, it would also require some time to learn if you're not familiar with it. jQuery greatly simplifies this though.
For our sample app, what would I gain by using asp.net MVC instead of
WebForms?
You'd gain better control over HTML markup and Javascript behavior, a cleaner separation of concerns and some easily testable codebase (even if you don't seem interested in unit testing it).
For our sample app, what would I lose by using asp.net MVC instead of
WebForms?
You'd lose the 'drag and drop' quick way of building your pages and the application state management.
Is it feasible to mix and match models within the same small
application?
In some ways, yes it seems.
I'd recommend watching this talk by Phil Haack, who gives a good overview of the framework and invites Jeff Atwood to talk about how he built StackOverflow with it.
He explains how SO is using some WebForms controls for CAPTCHAs which render themselves into the view.
The primary difference is that MVC is more like "regular" web development that the rest of the programming world uses, whereas standard ASP.NET was designed to make it brain-dead easy for Windows developers to become web developers. I learned web programming by learning Ruby on Rails, and MVC seems like it is becoming the .NET version of Rails.
MVC is much more oriented around standards compliance, unobtrusive javascript, and separation of concerns than regular ASP.NET. You'll need to understand how HTML and CSS work together. You'll learn a LOT more javascript as you master MVC. One of the biggest advantages of MVC to me is that you can use jQuery to do some amazing AJAX stuff easier and BETTER than you can in regular ASP.NET.
If you're just now learning web development then I strongly encourage you to learn MVC. You'll be able to transfer at least some of your new skills to other frameworks in the future.
If you're looking for which to learn to quickly get a web development job, then I'll have to strongly suggest ASP.NET.
Once MVC is RTM'd I think we will see a slow and steady adoption curve and as it matures MVC may become the primary framework for creating websites with ASP.NET. I hope so at least!
The biggest difference between ASPNET MVC and is WebForms is the lifecycle of an page, no difficult(unnecessary) postbacks, clean coding, enz.
There are no rules for that
???
REST-full website, Separation of logic
Design-time support, can't use third-party webcontrols
Please don't mix it together. If you really want to use the WebForms model you could use the MVP pattern, Billy McCafferty wrote exellent articles on that design pattern
I'm redesigning some of my applications from the MVP-pattern to MVC-pattern, not because MVC is better but I would like to use the newest techniques offered by MS(pattern itself is quite old).
Related
I'm a big fan of what ASP.NET MVC is doing, on many levels.
I'm about to take part in re-build of a very highly trafficked website, and I'm not which framework would be best (if any).
The site will need the following:
To support Javascript-heavy, highly interactive pages
But at the same time, provide underlying semantic HTML for search engines
Support multiple languages
Be skinnable
Expose a RESTful web-service API for partners
As far as I can tell, there's no reason not to use ASP.NET MVC for this.
I can present semantic HTML and layer Javascript on top using jQuery.
Multiple languages can be catered for using Resource files (same as at present).
Skinning can be done with CSS (it won't involve changes to the markup).
I can centralize business logic so that the Controllers and the WCF web-service use the same code.
But are there potential drawbacks to using MVC that I haven't considered?
I don't want to be the guy who picks a technology because it's cool but finds later down the track that it isn't very suitable for the job.
ASP.NET MVC is not good when all your doing is making a website that needs server-side code (but that's also true about ASP.NET also).
In your case I think MVC would be a great way to go. MVC has proven itself on high traffic websites (e.g. this one). However you must remember that MVC is new and changing. A library may not exists to do a specific task which means you'll have to write that code yourself.
Good luck on your rebuild!
You're good to go with MVC given what you've said about your project.
As far as I'm concerned, ASP.NET MVC is really only NOT good for situations where you have a large codebase in WebForms (meaning you have a lot of ASP.NET user controls, custom controls, etc). It's also not good if you are going to have people working on it who don't know what it's all about. Other than that, it's a pretty nice technology.
My two cents:
ASP.NET MVC is a great option but there is a little learning curve involved, so make sure your project plan/timeline has this handled. There might be developers on your team who might not be comfortable working with ASP.NET MVC, and this can cause possible delays (a lot of developers are still working in ASP.NET 1.1!).
#Alex: Lack of controls. Some features (like TreeView or Menu) are already implemented as Controls and it would be waste of time to reimplement them using mvc.
IMO the idea of using controls in ASP.NET MVC doesnt make much sense. You can create a treeview control using jQuery easily. Classic ASP.NET server controls carried a lot of baggage (viewstate etc) and hence ASP.NET MVC did not use any of those controls (though you can use helpers).
Finally, ASP.NET MVC is an alternative, not a replacement to Web Forms. I would not use ASP.NET MVC as it is still evolving, and my team is not very comfortable with it, but I guess slowly more and more programmers would shift to this (better) option.
I do not like ASP.NET MVC because of following reasons:
1.
Ugly routing API, there http://ayende.com/Blog/archive/2008/11/05/a-case-study-of-bad-api-design-asp.net-mvc-routing.aspx
is description of what is wrong.
By the way, friendly urls can be easily implemented without mvc
http://demo.liveui.net/bugtracker/Tasks/7
2.
Poor object model. It is proved that good software should consist of reusable components. There is nothing that can be reused in ASP.NET MVC based web site. For example, if you implemented smart drop down list once it will be difficult to use it again (even on the same web site).
3.
Lack of controls. Some features (like TreeView or Menu) are already implemented as Controls and it would be waste of time to reimplement them using mvc.
If I were you I would try to find some CMS and customize it for WebSite needs.
To responses:
YES. I know about ASP.NET controls disadvantages, but the question is about ASP.NET MVC. One can write a book about what is good and what is bad in ASP.NET but I do not think it is appropriate to discuss it here.
There are better ways of implementing MVC without using asp.net MVC. I have done it in the past, even before asp.net MVC came live. MVC is a pattern, not a technology, I do not understand why some people call it a Technology. You can separate all concerns by removing the code-behind from webforms and create your own controllers and routers and you will still have the advantage of the webform controls, etc to which most asp.net developers are used to use. asp.net mvc is nice for people whom do not really have the time to properly create an MVC app in a webforms environment and also to those whom do not have the time to architect a better solution. in conlcusion, asp.net mvc is good but there is a much better way of doing it and finally, MVC is NOT a technology.
I was wondering if someone could provide me with some answers. I've been asking to swap our internal apps to an MVC architecture for quite a while now. Rails was absolutely shot-down as a toy, Struts is just too huge for the apps we do, Django's name makes these old folks nervous (oil & gas industry) but finally, finally Microsoft has come out with MVC 1.0.
Since the Powers that Be are dead-set on using Microsoft technologies, I think I may be able to convince them to move our applications to an MVC pattern. Unfortunately, I can't come up with a good reason to swap to our forms-based structure to an MVC style.
Can anyone think of justification good enough to feed to my bosses? :-)
Do you have a good reason to switch? It sounds like you don't so I am wondering if you are switching for the sake of MVC itself which I would discourage you from doing.
ASP.NET MVC is helpful when you wish to have more control over the output and lifecyle of your application. Keep in mind that in many cases this means more work for you as the developer. MVC frameworks are good for sites that are not data-entry intensive - in other words if you handle a lot of form POSTs and process data out of those forms then ASP.NET MVC will actually create more work for you.
I don't mean to sound harsh but it seem strange to me that you want to switch to ASP.NET MVC but don't really know why.
There are a number of questions that address this in different ways:
Should I pursue ASP.NET WebForms or ASP.NET MVC
How to decide which is right, WebForms or MVC when doing ASP.NET
Traditional ASP .NET vs MVC
Biggest advantage to using ASP.Net MVC vs web forms
MVC Versus Web Forms
ASP.NET vs ASP.NET MVC
I think it's not a matter of "selling" MVC, but rather of understanding it's advantages.
also, you should seriously evaluate whether migrating an existing system to MVC will be cost effective.
however, MVC has many advantages - here are some from the top of my head:
separating control, data and presentation makes your application more maintainable
easier to make changes
after a relatively short learning curve, easier for other programmers to comprehend
better design means introducing new features is easier. try adding caching, form validation, etc when everything is mixed up...
an MVC system may be more testable (and therefor can be more reliable) - it's much easier to test your controllers than to test a spaghetti of data, control and presentation code.
I think that in this case the OP is looking for a pragmatic (profitable) reason to switch over to MVC, since most companies think that way.
The biggest advantage is that it is much easier to create unit tests for ASP.NET MVC applications. A good suite of unit tests can then serve as the foundation of a Continuous Integration process.
The bottomline for the powers to be is that you can create a build in a single step, simplifying deployment, creating installers, patches etc.
Rails and Django both follow the Model View Controller (MVC) pattern so sounds like you will just be creating a load of work for yourself. Why do YOU want to switch to ASP.NET MVC?
"Struts is just too huge for the apps we do"
In what way? Struts made even simple internal applications a breeze to develop in our company, once we had learned how it worked (which was quite quick). A few JSPs, a few Actions, backend database access done in JDBC via some simple DAOs, bundle it all up in a war with ant/maven and deploy. Done.
Also, fyi, keep Joel's advice in mind (Things You Should Never Do, Part I): avoid rewrite the code from scratch.
This is a difficult question to ask because it's so wide ranging.
Does anybody know of a scoring system of questions that would aid in choosing between a WebForms and MVC application at the start of a project?
e.g. Is TDD an important part of this project? (If yes score 1 for MVC and 0 for WebForms)
I would consider the following:
Current Skill Set of the team. If you have a large team that aren't going to pick up MVC quickly but are comfortable with Web Forms I'd stick with Web Forms
What level of control do you need? MVC gives you more control but that also means you'll be doing a lot of extra things your self. WebForms gives you a lot less control but there are a lot more things in the box. If being able to control the HTML output is important to you than maybe MVC is a better fit.
Will you need third party integration? There isn't a whole lot of 3rd party control support for MVC however there is a ton of support for webforms. Getting a nice grid in webforms is simple, however you'll be writing a lot of your own code in MVC to solve that problem
As you mentioned, is TDD desirable?
State management is a lot easier in web forms
I have a single question test (disclaimer: it's far from perfect, but does the job a lot of time in making you lean toward each of the technologies):
Is your application more form oriented (e.g. intranet stuff or something) or you are building an Internet-facing Web site (e.g. StackOverflow). In the first case, I'd probably go with Web forms. The latter case is probably better satisfied by ASP.NET MVC.
Another thing: these two are not the only paradigms out there. Before MVC days, I've done several projects by building HTTP Handlers that do the routing and other stuff that MVC does. You could also strip the Web form part of ASP.NET and just use non-server-form Web controls (while you'd do it in a standard Web forms project, I can hardly call this style ASP.NET Web forms).
Unless you are working on a very data centric app and need server controls with databinding and viewstate, I would go with MVC.
I haven't made anything serious in web form since MVC preview 2. MVC is much better with regard to design patterns and best practices.
And yes IMO TDD is very important and gives more than 1 point to MVC.
Usually, the decision to use WebForms or MVC boils down to controls. If you are going to be using a lot of server-side controls, then WebForms is for you. If you don't have that burden then MVC, at least in my opinion, is much cleaner, and more testable.
After using both of them the way I decide now is: Do I need to use server controls? If I don't then I default to MVC.
If you were stuck with WebForms for some reason then you could implement the MVP (Model-View-Presenter) pattern to separate the view from the logic and have some hope of unit-testing the codebehind.
I have seen the ASP.NET community buzzing about MVC. I know the basics of its origin, and that there are many sites (unless I am mistaken, stack overflow itself) based on ASP.NET MVC.
From everything I have heard and read about MVC it seems to be the future of ASP.NET development. But since I don't usually dabble in .NET web development I am left wondering the following: when is it appropriate to use MVC and when is it not, and why? Examples of great (and terrible) use of MVC would be fascinating.
Though I realize there are other implementations of MVC view other languages like RoR I am more interested on its impact for .NET programmers.
If this has already been gone over, my apologies!
Here are my 2 cents about MVC for web applications. For the sort of GUI apps for which MVC was originally intended, "listener" code was required, so that the UI could be updated when events altered the model data.
In MVC for the web this is unnecessary, you get your listener for free: the web server, and the HTTP request IS the event. So really MVC for the web should be even simpler. Indeed, it could be boiled down to the Mediator pattern, where the Controller mediates between the model and the view.
There are two things that there is a lot of confusion about. Regardless of conventional "wisdom":
Frameworks != MVC
Database Data != "Model"
"Full stack" web development frameworks typically add lots of features, and may or may not be MVC-oriented at their core. One of the features many frameworks add is database access or object relational mapping functionality, and because frameworks and MVC get confused, subsequently database data and the model facet of MVC also get confused. The model can generally be viewed as the underlying data for the application, but it does NOT have to come from a database. A good example might be a wiki, where the underlying model/data consists of file revision data, for instance, from RCS.
Hope this helps and I'm sure others will have plenty to add.
I would say one very compelling scenario to use MVC is if you have a group of experienced .NET developers who dont have experience with WebForms.
Coming from that situation myself (very little web experience) I found it I was much more productive and comfortable using MVC over WebForms.
I found it very hard to pickup WebForms due to the aforementioned abstraction - (I think proof of WebForms complexity is I have never met anyone who I would consider a WebForms "guru" i.e. knows the Page Lifecycle off by heart/Data Binding back-to-front etc.).
Using MVC actually allowed me to use my .NET and software experience without needing to heavily invest in learning the WebForms framework. Not only that but I got a much better understanding of HTTP, and this I think would allow higher quality solutions.
IMHO MVC allows you to factor code much better than WebForms, so I think developers with lots of "patterns" experience will be more comfortable in MVC.
ASP.NET MVC isn't the future of ASP.NET development it is just a new way of developing websites with ASP.NET. Microsoft have made it clear they will continue supporting and improving both WebForms and MVC in the future.
I cannot think of any websites, were it would not be appropriate to use MVC. You could also argue the same for WebForms.
Whether you choose one over the other is a personal choice, and would depend on the development team's experience and preferences.
I personally would never go back to WebForms development after using MVC on several big projects. WebForms in my opinion places an unnecessary abstraction layer over http and html. For quick prototypes you can get something cobbled together quicker with WebForms, but after that the complication of the abstraction makes things harder rather than easier. The only compelling reason to use WebForms in my opinion is the rich level of 3rd party controls that are currently available. But you can mix WebForms and MVC, so its easy enough to get the best of both worlds.
I work in a shop that has both ASP.NET and MVC applications. I think originally I was biased toward web forms because I worked with them from several years, but after working on a few MVC projects I prefer it.
Something to consider, however, is that if you have a team of experienced web form developers initial progress in an MVC application will be a slower because of the learning curve, so if the timeline for a project is very tight it might not be the best time to transition.
Aside from that I can't think of any situations where I'd prefer web forms over MVC at this point.
Based on my own experience, I can tell you that if you don't have any Winforms or Webforms background, you may feel more comfortable under the MVC umbrella because you are not "expecting" anything from the ASP.NET Webforms world.
On the other side, as a recommendation, I encourage you to check out other MVC frameworks like Django or RoR that are more mature to "be water" on the MVC way of thinking. I'm happy with ASP.NET MVC but looking other solutions helps you to understand better the paradigm behind the framework.
As someone with some winforms and client applications experience - is it worth going back and learning the way traditional ASP .NET pages work, or is it okay with moving straight into ASP .NET MVC?
I'm kind of looking for pitfalls or traps in my knowledge of general C#, that I won't know from the screencast series and things on the ASP .NET site.
Here is the great thing about MVC. It works closer to the base of the framework than normal ASP.NET Web Forms. So by using MVC and understanding it, you will have a better understanding of how WebForms work. The problem with WebForms is there is a lot of magic and about 6 years of trying to make the Web work like Windows Forms, so you have the control tree hierarchy and everything translated to the Web. With MVC you get the core with out the WinForm influence.
So start with MVC, and you will easily be able to move in to WebForms if needed.
I agree with Nick: MVC is much closer to the real web paradigm and by using it you'll be confronted with how your website really works. WebForms astracts most of these things away from you and, coming from a PHP background, I found it really anti-intuitive.
I suggest you directly jump to MVC and skip WebForms. As said, you'll be able to get back to it if needed.
ASP.Net Webforms is a completely different abstraction over the base framework than ASP.NET MVC. With MVC you've got more control over what happens under the covers than with ASP.NET Webforms.
In my opinion learning different ways to do things will usually make you a better programmer but in this case there might be better things to learn.
ASP.NET MVC is for developers who desire to decouple the client code from the server code. I have wanted to write JavaScript, XHTML, CSS clients that can move from server to server (without regard to server technology). Clients are time-consuming to fit and finish so you would want to use them (and sub-components) for as many servers as possible. Also this decoupling allows your server to support any client technology that supports HTTP and angle-brackets (and/or JSON) like WPF/Silverlight. Without ASP.NET MVC you were forced into a hostile relationship with the entire ASP.NET team---but Scott Guthrie is a cool dude and brings MVC to the table after years of his predecessors (and perhaps Scott himself) almost totally focused on getting Windows Forms programmers to write web applications.
Before ASP.NET MVC, I built ASP.NET applications largely based on ASHX files---HTTP handlers. I can assure you that no "real" Microsoft shop would encourage this behavior. It is easier from a (wise) management perspective to dictate that all your developers use the vendor-recommended way of using the vendor's tools. So IT shops that are one or two years behind will require you to know the pre-MVC way of doing things. This also comes in handy when you have a "legacy" system to maintain.
But, for the green field, it's MVC all the way!
It depends on your motivations. If you're going to sell yourself as an ASP.NET developer, you will need both.
If this is just for your own pleasure, then go to MVC.
My personal feeling is that webforms will be around for quite a few years more. So many people have time and energy invested in them. However, I think people will slowly (or maybe not so slowly!) migrate. Webforms was always just a way to get drag-and-drop VB4 morts to think about web development. It kindof worked but it does take away alot of control.
IMO, there are more pitfalls in normal web forms scenarios than with just MVC. Viewstate and databinding can be tricky at times.
But for MVC, it's just plain simple form post/render things old-school way. Not that it is bad, it is just different, and cleaner too.
I can't really speak technically about MVC vs "traditional" as I have only used the traditional model so far. From what I have read though, I don't think one is vastly superior to the other. I think once you "get it", you can be very productive in both.
Practically though, I would take into consideration that most books, code samples and existing applications out there are written for the "traditional" way. You have more help available and your skills will be more useful for employers with existing applications written in the "traditional" way.
If you don't know how or haven't has experience with raw level web request / response and raw html/css rendering then MVC will would be good place to start.
You will then better understand the pros and cons of both webforms and mvc. They will both be around in the future as the both address different needs.
Though I will say webforms is a highly misused and abused platform.
So much of the "look no code" rubbish gives all who use it a bad name.
Put in the time to understand it and use it properly you'll find its a very extensible and robust platform.