As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Let's say that you will start a new ASP.NET web site/application tomorrow. Would you chose Web Forms or MVC, and why?
MVC baby! And JQuery!
Edit: OK, it's fair enough to say my response warrants a little more info.
I'd choose MVC for the following reasons:
I have worked in Rails and found it highly productive. ASP MVC has borrowed so much from Rails that it feels like a direct port in some ways (and that's a good thing in my mind).
AJAX is important, but I hate the Microsoft "Atlas" approach to AJAX (whatever the product name is these days). If you're going to do AJAX, you need to understand the HTML and the JavaScript. Frameworks that hide that from you are hurting you more than they are helping you (IMO).
JQuery has taken over the world it seems in terms of JavaScript frameworks. ASPMVC is well-integrated with it. I want to learn it, so there's great alignment here.
The whole "control" model is a neat idea, but it is more complicated than it appears on the surface. For example, look around on SO for questions about how a UserControl can find its highest level containing control and so forth. The control hierarchy abstraction has leaks in it. Grids are great if they do what you want out of the box, but it's very very hard to customize them to do something they weren't made to do. And the best grid controls on the market (the ones that are highly customizable) are large, bloated, overly complicated beasts. Maybe that shows us that we should drop back down to HTML and let loops in our views do that kind of thing for us.
I believe I can build complete, beautiful apps in ASPMVC much faster than in ASP.Net (and I've got some years of ASP.Net under my belt). Look at StackOverflow ... built quickly on ASPMVC with JQuery, and it's fast, scalable and a joy to use IMO.
Oh, and it's completely open source! It is ok to read the source code, blog about it, and even modify then redistribute it!
I would choose MVC simply because it's designed to be testable and mock'able. That would be the major factor in my decision.
WebForms are much more difficult to Unit Test because they're rooted in several concrete classes that are difficult, it at all possible, to Mock. These include HttpContext, HttpResponse, HttpRequest and HttpCookie.
MVC is designed to be testable and it's API greatly facilitates doing so.
Good article on the testability of MVC: http://dotnetslackers.com/articles/aspnet/ASPNETMVCFrameworkPart2.aspx
Personally, I have decided to use both...
If it's a website (viewed online), I have decided to use ASP.NET MVC.
If it was an application (web application with a single purpose) I have decided to use web forms.
This decision is purely based on the case use and the solution you trying to deliver. If you are interested in good SEO and a faster website, MVC is much cleaner HTML and faster than web forms.
However if you after a complex functionality with a lot of filters, grids, postbacks on the same page and you are well experienced in Web Forms, just stick with it.
If I were starting today I would probably still stick with webforms because of the volume of knowledge and resources surrounding it.
That said I really want to give MVC a shot and as others have mentioned the excitement within the community means it wont take long before there is a lot of support for it.
MVC FTW!, Reasons?
Total Control over my HTML
No Web Forms magic
No complex page life-cycles
Closer to the metal
It is the natural thing to use with HTTP
Is MVC the "flavor of the day", or does it have staying power?
I have worked with MVC, and have a vast amount of webform experience. I often wonder about the staying power of MVC.
You should consider this when choosing one or the other. What do you want to support for the entire product lifespan?
I can't say which I'd really go with having not tried MVC yet. But I'd be a bit worried about using it for a really big enterprise project as yet.
Scroll through pass questions and you'll see that there a lots of questions/issues with MVC (compared to good o' WebForms that is). That alone has me worried. And a lot of the questions seems to be for special UI needs. Again having not tried it I don't know how mature it is yet but I'd still be a bit worried.
Maybe someone who has used it for an enterprise project can shed some light.
While MVC is the new kid on the block there are still a lot of benefits to designing with the Web Forms model.
Familiarity with the tool
consistency of look/feel with existing projects
Tooling/designer
Postbacks
Event driven
Controls to abstract
3rd party controls that work
Rapid development
Declaritive style
Rachel Appel did a great presentation at MIX on this very topic. You can view the video here:
Choosing between ASP.NET Web Forms and MVC
http://videos.visitmix.com/MIX09/T23F
I would choose Webforms for local/intranet applications with rich business logic and MVC for public/internet site (blogs/forums/presentations/simple services). "WebForms application model" is preferable in areas where rich state support is critical
I have started a new Web site for our own product a week ago and I couldn't be happier with ASP.NET MVC. Everything seems natural, I always know where to go and look if something doesn't work or does not look the way I intended.
Frankly, the biggest chunk of time I've spent has been CSS. Coding, integration with jQuery... peanuts.
OTOH, if you are not experienced developer, ASP.NET will not appeal to you as it encourages you to go all the way and control all aspects of your site - HTML markup, CSS etc., which in turn means no controls, drag and drop visual editing etc.
Unlike traditional ASP.NET where you are left to yourself and often end up mixing all kinds of UI, persistence (DB) and business logic code in various pages, MVC will guide you and help you structure your app much more consistently. This will not sit with you if you don't like "opinionated" frameworks and/or just want to get the job done without caring about structure of the site, maintainability, scalability etc.
Note that it's perfectly possible not to care about this if all you're building is a one-off intranet site, but for public Internet site I'd choose MVC over classic ASP.NET every time.
MVC
... it just seems so obvious that's where the future is
In ASP.NET MVC you sacrifice your controls toolbox,
URL routing is already in ASP.NET (web forms)
So I would stick with ASP.NET web forms ( I'm not saying that MVC isn't good.)
jQuery, do you think the IT folks will let you use it?
ASP.NET MVC because I want to learn how to use it.
I would currently choose ASP.NET MVC for 2 reasons: 1) I want to learn to master it. 2) There is already a great community forming around ASP.NET MVC and everyone seems to have very positive entergy regarding it's use. I can't wait to see where it all ends up and I want to be part of it.
I would like to go with MVC. I always seam to be fighting the abstraction when I work with WebForms.
To use WebForms effectively you actually need to know more about how the web works than if you use something like PHP. I find myself using <asp:Literal instead of <asp:Label to avoid putting a <span> around the text and running labs to figure out the order of events, etc.
it really depends on the project, since i havent build anything with MVC and if the project has a short time delivery, i will probably find some hinders in MVC that could make me not to deliver the project in Time.
I wait for MVC on .net for a long time.
I think more than 90% people will choose MVC rather than webform.
If it was a personal project then I would use MVC. Just to learn more about it. If it was a project at work I would use WebForms, possibly in combination with DynamicData for the administrative parts. The reason is that I would be more productive with a technology I know, and using DynamicData for the administrative part would let me setup that part in minutes.
As always it depends upon the type of application you are developing and the individual circumstances. A lot of our internal applications are being developed in SharePoint as that is our internal platform of choice for intranet type applications.
This automatically limits us to ASP.Net on the standard model.
I really want to get to grips with MVC, but I don't have a justification for this at work and I have 2 kids and a wife at home so no time to develop at home.
Sometimes circumstances force your hand, if only we all had the choice of exactly what platform, framework etc. to develop with.
I am currently working on a project in Asp.net MVC with jQuery and jQuery-ui, and it's a lot of fun.
If you're familiar with html and javascript (or other MVC frameworks like rails), MVC makes much more sense than the old webforms. And you control the output, not some vague control on a form, so if there is an error on the page or if you want to change the layout you can :).
MVC. We're going to redo an application that is SEO intensive and MVC seams to fit right in out of the box. Plus I want to hang out with the cool kids on the playground.
I just released a major public site on the MVC platform after using webforms for all previous projects. Without a doubt it is the way to go, IMO.
With webforms, I have found the sites tend to become a mess over time as you have blocks of code in the code-behind that handles both view logic and controller logic. As the site grows and the logic gets more complex it is difficult to trace what is happening and where.
I find that that MVC forces you to break things up in a more logical manner. Controller and model classes allow you to get a better control on the organization of the application. In addition, views are more flexible because there is a specific way of providing data to them, through models.
Also, like others have mentioned, you have more control over the markup and urls and it plays nicer with client libraries like mvc.
The only time I would use MVC is if I was building and intranet site that was focused on reporting data of some sort where the built in controls that come with asp.net would save development time and I wasn't as concerned with the look and feel. I would never use asp.net webforms again for a major public facing site.
Both!
I am making the long haul to MVC. I have too much code that readily works in Web Forms. MVC is fantasic, but it sill leaves a lot in the productivty areas such as templated grids and lists, basic UI controls (calender, autocomplete, etc.) and scafolding. These are all areas where Web Forms excels at, but comes off the rails if you want precise control and want to keep things simple.
MVC 3 and EF Code-Only could be a great marriage if they are willing to bridge the gaps between the two. Most people that use Ruby use it for Rails, and ActiveRecord makes that easy to work with.
Also I would love to see a parallel "Feature Pack" project for MVC with MS support, similar to the way they did the Microsoft Ajax Toolkit, that would say have quarterly updates. I find MVC Futures and MVCContrib both lacking. But I know they only have so much budget. So, here's to hoping that MVC 3 changes all that.
Just say NO to ASP.NET MVC if you are developing for Intranet. For Internet, sure.
Hmm.. At the moment I am confused like you are and about to start building a new site :). I was going to start with Webforms, but now I see where the crowd is heading and I think I am going to give MVC a whirl now.
Thanks for asking this question.
Now that it's RTMed and now that there are some very good resources on it I would say ASP.net MVC would be my strong preference, but it's not cut and dried.
Web forms hasn't gone though, it's still there, it's still supported and I've worked on several major sites and used Web Forms very successfully, so if there were other external factors such as a customer preference, or perhaps a team that had solid Web Forms experience then I'd still be happy to work with Web Forms. That said I have already worked on one project with MVC (while it was still in preview), and I much prefer it - my reasons are similar to those given above so I won't repeat them all. I will say that if testability isn't the best reason it's certainly in the top one:).
I would choose MVC since designers and developers can work in parallel on the same project. Designers can work on the view part (JavaScript, CSS, HTML) while backend developers can work on the controller code.
I would like to be doing ASP.Net MVC, even though I'm still very new to MVC. But it's not to be in the foreseeable future.
I'm actually going to be starting a rebuild of a web site in the next couple of weeks that was horribly written in ASP.NET 2.0 and I am going to be using ASP.NET MVC. For a lot of the same reasons as above. I would rather not use custom .NET controls and handle the HTML/JavaScript (using jQuery) myself. I do a lot of Java web development as well so having a good understanding of the underlying HTML/JavaScript/CSS is important to me.
Related
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
What’s your choice for your next ASP.NET project: WebForms or MVC?
Can you list some reasons that would make you use ASP.NET webforms for a new project, instead of MVC? I've heard a lot about the opposite, but not things that are done easier or better with webforms. I'm not talking about developer preferences here, but rather technology features and how they map to project features.
The only argument for WebForms is the need to design highly complex (read cluttered) interfaces with a whole lot of interconnected elements which in all or in part should react to changes in other elements.
A typical example would be some enterprise application (from SAP or smaller vendors). They usually have interfaces bordering madness. You'd have a hard time trying to synchronize the controls manually with JavaScript if you were on MVC. With WebForms it's by far easier.
Whether it is a good idea to build such interfaces is another matter entirely.
In WebForms element events trigger a page postback. They go to the same url and are processed in a unified manner. This is what makes the architecture very scalable.
With MVC to accomplish this you would have to set up a bunch of service urls to handle posts from different controls, then process those posts and update view models accordingly. This all involves a lot of trickery and juggling. Not that it is not doable - it is, but not on a big scale. This approach would not be scalable. Sooner or later you will arrive at the understanding you'd need to build your own framework in the direction of stateful object-oriented HTML/HTTP abstraction like WebForms.
A few things that could push me (back) towards WebForms:
I need to produce something that can be taken over by someone who isn't primarily a web application developer (say a WinForms programmer), and the app could substantially be maintained through Visual Studio's Forms Designer. The IDE support makes the development model closer to that of WinForms.
An app that needs to look Ajax-y but will be maintained by someone who won't learn JavaScript. I think things like the UpdatePanel (while horrible in so many ways) are actually pretty good for that scenario.
Possibly for some kind of demoware, again because of the IDE and ASP.NET AJAX. Fairly quick to knock up some reasonably smart screens without too much thinking.
I need a powerful CMS and need to stay within .NET. At this point it looks like there's better choice in WebForms than in MVC (though hopefully that's changing).
I'm working with a team who are already familiar with it and aren't going to learn MVC.
Of those, probably the CMS is the requirement I could think of right now that would actually make me use WebForms.
If you only know webforms MVC comes with a learning curve so you will need to spend quite some time training (or risk making serious security or performance errors)
You need a tiny little app NOW It probably is quicker to build a throw away mock application in webforms if you go for the anti-pattern. E.g. SqlDataSource, Logic in your code behinds etc.
Rich controls GridView is an excellent control, having sorting etc all built in for you with little code needed as long as your custom requirements are small.
Lack of web development experience Web forms is just easier. It takes more concerns off your plate. Much better for a newbie as its tough to go wrong.
Having said that, if you know what you are doing or have the time to learn and you want to build a long lasting site, MVC is soooo good. And more fun too.
I'll add that there is nothing really wrong with web forms. It's perfectly possible to build high performance app with it. It's just times have changed since it first came out and MVC has addressed those changes well.
Personally, i find MVC very good for admin-pages. because they usually have a load of tables, and are made for data input and editing. MVC is 'made' for those things, so it's going very fast making those pages.
webforms I use for more complex things, like the User-end of the site. the site i make shows courses people can take. the registering for a course is a 5 step procedure, which in MVC, I have no real idea how to do it. I'm sure it can be done in MVC but I think it's better/faster in webforms.
however in the end I do like MVC more. It feels so much cleaner to work with.
The only time i would consider going with Web Forms in a new project is if there was a component created for Web Forms that solved a specific problem that would be much harder to solve using MVC.
I can no longer see any advantage of Webforms over MVC, apart from some upskilling effort which should not be prohibitive.
[Originally I believe MVC wasn't compatible with webcontrols, so wishing to use Dundas chart control for example wasn't possible. That would have been a good argument for using webforms depending upon your requirements. But I believe this is no longer the case, and anyhow, you can include webforms in your MVC project as a worst case.]
It depends!
The difference between WebForms and MVC is if you can TDD and control the complete markup.
I have read several other posts here, so i get the idea on the pro vs. cons, especially having full control over the rendered html code etc. (in MVC).
My question is regarding the UI controls: In MVC, i will have to write all UI controls myself (or the html equivalent). Now is that not going to be very difficult?
The reason why these 3rd party vendors for asp.net are there is just because of the fact that it is difficult to write UI controls for ASP.NET all by ourselves, and be able to target to all web browsers, and also that we are better off concentrating our time on the business logic rather than spending the whole lot of time writing the UI controls HTML code ourselves.
I understand that this feature gets us the full control over the final html, but is it not counter-productive to do this UI bit ourselves. If it was so easy to write them ourselves, how come these 3-rd party vendors are all living now. We could have done this all by ourselves all these years of WebForms days.
I am sure i am missing something here or being a little stupid, but please enlighten me as to what i am missing in specific regard to the UI bit being written by ourselves.
Just because i get full control over the program by writing in IL code, do we go and do that? We still use C# and things like that - So that theory of "having full control over html" - i am not bought into that idea.
Please help in getting my head around this UI bit.
Other things i understand, about the separation of concern, TDD based development possible with MVC etc.
But why would i go around writing the UI controls all by myself - it is a bit a work isn't it?
The thing is:
If you want to master in web development you have to master HTML + CSS + Javascript
And with WebForms you have to learn the WebForms way to do it, but with MVC you have the power of .Net with the freedom to generate the HTML + CSS + Javascript you want.
Here's a new rant on the subject http://www.charliedigital.com/PermaLink,guid,6dcb0333-9d70-40c7-975b-0ff4011c4661.aspx
Problem is, ASP.NET MVC is much younger product than ASP.NET. For many years 3rd party companies have been developing TONS of reusable components, and I believe that it is only a matter of time before comparable set of controls will be available for ASP.NET MVC.
If you really need very rich GUI with 3rd party controls, and you can't rewrite them in acceptable time - stick with asp.net. Altough in my opinion, MVC gives you tons of power it wouldn't be wise to spend much more time rewriting controls than you can save. If you can live without controls, and like MVC concepts - use MVC, and you'll most certainly see 3rd party solutions as soon as they'll there is growing market (maybe thay've already noticed that, I don't know) for mvc extensions.
I believe that the UI and the user experience are vital to the success of a web app. Making the page intuitive and easy to use, minimizing the amount of navigation the user has to do to get the job done, and providing effective feedback and interactivity can make all the difference between a site that users want to use and one that they avoid.
If you are trying to attract users on a public website, a pleasing appearance and excellent usability are key to building repeat visits.
If you are writing an intranet app to be used by hundreds or thousands of employees all day long -- as I mostly do -- making the UI efficient and easy to use really means a lot to your users.
So, I wouldn't downplay the importance of the UI. It isn't a nuisance. It's a key part of the user experience. I suggest that a web developer should embrace whatever tools and strategies that will get the job done. That often means coding the UI controls yourself. Or working with a teammate who likes doing that part of the work.
I recently refactored a very complex website using ASP.NET + handworked javascript to MVC + jQuery. The complexity of the code was reduced by 50%-75% and became much more testable. I replaced all the complex webcontrols I had to write (with a steep learning curve I had to overcome) with very simple HtmlHelper methods.
Don't forget, when you use custom webcontrols, you are given a very static UI by the control developer. With raw HTML, you can take advantage of styles and ui developed by the whole web industry.
Increased simplicity, decreased development time, testability, flexibility in UI... I don't want to go back.
You also have to remember that ASP.NET MVC is just the first release. I don't think there is intrinsically any reason why you couldn't have the equivalent of server controls to enable certain tasks - remember, there are many server controls that don't generate any mark-up (such as the Repeater, PlaceHolder, ListView). These type of controls could be useful in a future MVC setting, I think.
I believe that ASP.net came around when lots of developers were still used to doing desktop applications and just beginning web development. AT that point in time abstracting the details of the web with controls and post backs was a great way to get people started. At that point we weren't trying to perfect the web, we just wanted to get on it!
Now that the web has matured and we've all slowly learned about html, css, javascript and the likes we want to optimize our websites for our own needs and we don't want to depend on ASP.net Forms controls to control the fine details of our websites.
In summary, I think this is about the natural evolution of many developers from the desktop to the web
I for one, am very thankful that you cannot use ASP.NET controls in MVC.
Controls, as many have already pointed out, are just server side blocks of code that render HTML and javascript on your behalf. Things like a datagrid are great, until someone asks you to make a slight modification, like having a delete confirmation alert, and then it seems impossible to do certain tasks.
The good news is that there are very powerful jQuery tools written to help you. jQgrid is a great grid replacement that does WAY more than the ASP.NET grid...
http://www.trirand.com/blog/
jsTree is a treeview that is fantastic. Again with the jQuery....
http://www.jstree.com/
And the truth is that most things you can do with razor, HTML, javascript and CSS. It's so simple that it's just stupid.
It's hard for people like myself who were web forms developers to grasp MVC and why you should use it because it's so simple. It's difficult to let go of the complexity of conventional ASP.NET. But it feels so good when you do.
And don't mix web forms with MVC. You can do it, but you will wish you hadn't.
Here is the key thing that I think you are missing. When ASP.NET is no longer the MS way of doing things...you will eventually be forced to move on and do something else. I have programmed in perl, ASP classic, then ColdFusion, then PHP, then ASP.NET web forms, then ASP.NET MVC...the only thing that they all have in common is the underlying database, design patterns, best practices for a given set of technology AND...HTML, JavaScript, CSS, and Photoshop.
No one is asking you to learn MVC. No one is telling you to not use WebForms. However, complaining that you have to write a raw UI is not going to get you very far in this industry. You should be learning something new every day...and it sounds like some time spent on HTML and CSS would be a great place to start your focus!
The biggest problem you have with relying on third party controls is when a client asks you to do something that the third party controls don't cover. If you can't replicate their complexity plus the added feature request on your own you are skirting a possible failure in your professional livelihood! You will need to know how to do it all...eventually!
I generally suggest that you embrace new technologies. You don't have to use them...but you should at least know how. This way you will know what the best tool is for any given project.
I've been wondering - what's an equivalent of 'control' from webforms in asp.net mvc? It's not a partial view for sure. What else it can be? Controller + partial views via partial requests?
Maybe i'm dumb, blind or both, but i haven't seen any 'control' for asp.net mvc. Just a lot of code snippets to accomplish one specific thing or another.
I believe that asp.net mvc is quite unfriendly with rapid development. Only way out of this problem - a lot of open source code (like MvcContrib), tutorials, sample applications & most important - slightly smarter developers.
You do not have to replace Webforms controls with something else from MVC. Just mix them - http://www.hanselman.com/blog/PlugInHybridsASPNETWebFormsAndASPMVCAndASPNETDynamicDataSideBySide.aspx
Well, I was also wondering how to use 3rd party controls in ASP.NET MVC. Obviously, and contrary to some answers here, it had to be possible.
As much time has passed since the question was asked, the industry has evolved. So I've searched and found (but havent' yet tested) solutions such as Telerik Extensions for ASP.NET MVC .
I'm posting this answer here mainly to support other MVC newbees such as myself - Just Google
"asp.net mvc" controls
I ask this not to start anything negative. Rather, after looking at ASP.NET MVC it hit me (duh) that I am not using controls like on webforms but coding html markup by hand (gasp.)
Is this a move backwards? I remember coming from classic asp to asp.net and dragging and dropping controls, creating a bll, etc. now it seems I am doing all that by hand, again, like classic, except I have good mvc design.
I guess I'm trying to figure out why this is a move forwards from what was a rapid development environment to what appears to be more tedious.
EDIT:
I always thought Visual Studio .NET was one huge reason to go with ASP.NET with all its controls and automation. Now with MVC it is makes me think it's just like any other MVC with a decent IDE, since I'm doing everything by hand now.
"Classic" ASP.NET hasn't gone anywhere - you can still use it if that's what you want or need
Though you may or may not get "drag-and-drop" functionality, between AutoComplete and the various render helpers you can easily get a working view in minutes
Creating the views is only a small fraction of the overall project
Even in ASP.NET I rarely used the visual editor. I always felt that it got in my way and made decisions for me, wrongly.
Is a step forward:
the code is fully testable
you gain full control of what the server is generating
no more viewstate!
increased server response speed
less server cpu load without the WebForm's Page lifecicle
a programming model which is more close to the web (webforms aimed to bring to the web the desktop programming model).
....
Funny you should mention this - I just finished reading a chapter in "Professional ASP.NET MVC 1.0" that answers this exact question.
The book they compare the difference between Web Forms and MVC as the difference between leading an orchestra and composing a song. MVC doesn't give you the same level of immediate response as web forms, however it does give you a level of granularity a lot of web developers have come to expect. It's well known that ASP.NET controls, even in their later versions, inject more HTML than is desired.
So, functionally yes it's a step back, but only because you've been given complete control over what gets put on the page. As always, pick the right language for the job.
It's a step sideways, rather than forwards or backwards; just another way of doing the same thing, with a different emphasis. With ASP.NET forms, it's easy to "draw" the page so it looks roughly like you want it to look, but it's hard to make it behave like a proper web application. With ASP.NET MVC, it's not as easy to throw together the appearance of it, but it's actually easier to make it behave like a website, with URLs that describe the content being returned in a predictable way.
Tell me about it. I'm still trying to work out why I'm subjecting myself to this. Ultimately the number #1 sell is Unit Testing. For those of us who don't subscribe to this, the advantages are few, if any, IMHO.
That said, I'm open to be convinced otherwise. I think that MVC is a good foundation, but like you say, it's very very tedious at times. The RAD system of drag/drop controls from the toolbox used to be terrible, but since vs2008 it's been quite a pleasure. I expect the major toolkit vendors like Telerik, Infragistics, ComponentOne et al will soon ship MVC friendly toolkits (I hope!).
I'm only learning it because I'm currently on a project that was built on it (not my design). Don't forget though that YOU DONT HAVE TO USE IT. Classic ASP.NET didn't disappear. :)
-Oisin
For me, getting rid of viewstate and the page life-cycle has been an addition by subtraction. :) Not to mention a boon to my knowledge of web programming because of having to get my hands "dirty".
Some people might say that ASP.Net was a step backwards in that it can constrain the flexibility of the application by locking you into using pre-built controls.
Classic ASP was immature, but it did give you very fine-grain control over the mark-up code, which many find is lacking in vanilla ASP.Net.
As I see it the ASP.Net MVC paradigm gives the developer closer control over mark-up, while still giving access to all of the advantages of the .Net framework.
I think it was a necessary step backwards, or better yet backtracking a few steps to move ahead.
The web had evolved in a direction that diverged significantly from ASP.NET's core design premise.
In the end, comparing ASP.NET to other agile web frameworks, I believe it was a case of "you can't get there from here".
I thought part of the point of the ASP.Net MVC Framework was giving the developer more control over the HTML. Something the drag-and-drop controls make a mess of.
ASP.net MVC is not for everyone or for every application (some may argue this through!). MVC is a framework you can use in its basic form or extend to your hearts content. It allows you full control over what is rendered to the user.
MVC has a number of advantages:
Seperation of concerns resulting in better testability, arguably better design and easier to modify UI
Full control over what is rendered - which can result in standards compliant, smaller, faster pages
Clearn SEO friendly URLs although ASP.net 4 has routing features
In its purest form without use of session load balances very well.
It also has some disadvantages:
Learning curve and change of thinking required
Lack of 3rd party support although this will change
Pages can look cluttered
Can be more difficult to develop certain types of controls e.g. something like a reorderable data grid or something with many steps like a wizard
I think it's a step in the right direction, but it's nowhere near as mature as WebForms. I expect to see commercial 'control' libraries before long, although it won't be drag and drop stuff.
Also, if you're using WebForms for your view engine you're missing the point, in my opinion.
One of the biggest differences is the page life cycle. This is for me the main paradigm change. Many other benefits could be addressed following good practices, although ASP.NET did not enforce them.
If you are used to WebForms and ASP.NET, MVC may seem awkward, but if you come from classic ASP, PHP, Rails o any other environment that respects the nature of the HTTP flow, its a good option. You get the benefits of a great IDE such as Visual Studio, a complete and powerful framework such as .NET (whether you use C# or VB.NET) and everything works in a more or less familiar way.
You may lose ASP.NET controls and visual designer but for many people that was more an annoyance than a benefit, depending on the type of applications you were building and your previous experience. ASP.NET was a nice transition from Winforms but for people who always worked on a web environment seemed a bit "forced".
Didn't Scott Hanselman at one point say that "MVC isn't Web Forms 4.0"? I've taken from that, that he means that MVC isn't to replace ASP .Net at all, and it is simply another option to Win Forms and Web Forms.
I do agree in that when I first started looking at MVC, I was much more reminded about classic ASP (not the .Net version) in the way that there's no code behind page, and there's more <%= whatever %> markup in the views, which threw me for a little while, as when I used ASP .Net for the first time, it was as though ASP .Net discouraged the need for such markup.
Personally, I like MVC; I think it's great, but there's a little room too for ASP .Net..!
So I'm about to start of a small project for my sporting club for member registrations and I'm trying to decide between WebForms or MVC.
Allit will be is a user login and data capture forms (or and data retrieval), so I was initally thinking WebForms with FBA but I've wanted to have a play with MVC for a while and I was thinking that it wouldn't be too bad a choice.
But not really having a lot of knowledge of MVC I don't know if it'd be a wrong fit.
So what's a good way to decide if WebForms or MVC is the right choice?
Is this a critical, production level application or a small one-off? Can you deal with the extra time that the learning curve of MVC will take or do you need to have it done right-away? Can you afford to scrap the whole thing and start over if MVC doesn't work out? Are you willing to have the platform change (probably not much now that it's in beta) while you are developing? Is there another project that is less critical that you could use MVC on to learn it.
Depending on how you answer these questions, learning MVC on this project might be worth it. Personally, I think it is a better architecture, but a less mature technology at this point. It has certainly increased the testability of my web code. I expect to move all of my development in this direction over the next year or so, though I doubt if I will change gears in any of the projects that I have had under development for awhile. I've just started my first new project in MVC. I wasn't willing to commit to it until it went into beta and I think that it will be in production before I'm finished with the project.
I actually really like the WebControls methodology. A lot of people are saying that "when doing MVC it's easier to Unit Test". First of all you should anyway what type of methodology you're using have a clean separation of Business Logic and your UI layer. If you do that then you can Unit Test your Business Logic regardless of which methodology you're using. Sure it might be easier and "come out of the box" with MVC, but it's not some Magic Silver bullet which is the only road that leads to Rome...
Second of all you could use WatiN which makes your app testable in ways that are far superior to conventional Unit Testing. (note I don't mean it should replace Unit Testing, but in addition to Unit Testing it takes you to a level of security previously impossible to gain)
Thirdly, the web is stateless. This is because of that HTTP is a completely stateless protocol. This is exactly what makes the web beautiful, but at the same time very difficult to develop applications for. The WebControls methodology mostly fixes this completely by having concepts such as ViewState. This takes away a lot of the hassle when doing application development. Have a look at this Ajax Calendar sample which is mostly impossible to achieve with the same (small) amount of code in any other paradigm then WebControls (disclaimer; I work with Ra-Ajax myself)
Now have a look at Stacked (Disclaimer; ...which I also work with BTW) then realize that I have so far spent less then 3 days developing what you're seeing there. Maybe someone could peak that accomplishment with MVC, but I doubt it...
I think the WebControl paradigm is very beautiful. Sure it has lacks on some points, but guess what, so does everything. The only "Silver Bullet" that exists in programming as an art form is that there doesn't exist any Silver Bullet.
When that is said, I know that Grurrah is using the Castle Project's MVC layer in addition to a WebControl based Ajax library. So to mix WebControls and MVC might be difficult, but surely not impossible...
I think MVC has gotten a lot of "deserved" hype, but unfortunately also in that process a lot of undeserved hype too...! :(
Make up your OWN mind, don't listen to the MVC evangelists trying to convince you that they have found the "Silver Bullet" to programming for the web. And wat's more, don't believe me either! I too have an agenda (get adoption to Ra-Ajax)
Make up your own mind. Asking someone if you should do MVC is like asking should I eat apples or oranges... The only GOOD answer you'll EVER get is; "It depends"...
IMO, MVC is the way to go forward. If you have the time to learn the MVC programming way (because you hinted that you wanted to play with MVC .. meaning, you haven't used it yet), then this would be an excellent opportunity to dig into the product.
The learning curve is not high if you have previous WebForms experience (which i'm guessing you do).
If you need to make a site really quick, don't care about what it is and the site will be small, then go WebForms. It's the quick and nasty solution (for my opinion only). WebForms work 100% perfectly well. All my sites have been WebForms and they are fine.
Summary:
Got time and want to learn the best way to make sites: MVC
No time or don't care: WebForms.
gl and hth.
We were presented with the same opportunity. After playing around with MVC for a few weeks, we discovered there were things we didn't fully understand, as well as, things that were going to involve some changes:
Implementing a the Repository design
pattern
Html Helpers vs standard Web Form controls, like Repeaters and GridView
Caching
Whether to use the framework we currently use, Csla, or try to move to just Linq-To-Sql with partial classes to hold the business logic
Complex classes and user interfaces that involved master-detail classes
We decided to continue playing around with it and wait until it is officially released and then write an internal application and see where it leads us.
Webforms is an abstraction of the web for folks who come from a gui world. I find it has alot of advantages, especially in the RAD sense, but when writing big beefy apps you often end up painting yourself into a corner it is very hard to get out of (ie: everything to do with viewstate.)
The other problem is you sort of fall into bad practices with webforms. You should not be using drag and drop datasources, built in grid controls, and most definitely not have business logic in the code behind if you want something that is scalable and maintainable with a clean architecture. To do that in webforms requires forethought and discipline, because everything steers you in those directions.
By contrast, with MVC you sort of fall into best practices. It is more performant (the whole page life cycle/viewstate thing chews perf on both client and server), and far cleaner from an architecture point of view.
The downside is that you can say good bye to RAD, and you will actually need to have decent knowledge of css/javascript to make good looking pages.
It really comes down to best tool for the job, and the type of experience/knowledge you/your team has.
Based on your comments to tvanfosson, it sounds like MVC would be a good choice for you as you listed your desire to learn as a reason to choose that technology. I doubt MVC will change drastically from its beta. So, this could be a good opportunity to learn a new tool. As for as WebForms being the "quick and nasty" solutions, I worry that is MVC propaganda.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
What are some of the advantages of using one over the other?
The main advantages of ASP.net MVC are:
Enables the full control over the rendered HTML.
Provides clean separation of concerns(SoC).
Enables Test Driven Development (TDD).
Easy integration with JavaScript frameworks.
Following the design of stateless nature of the web.
RESTful urls that enables SEO.
No ViewState and PostBack events
The main advantage of ASP.net Web Form are:
It provides RAD development
Easy development model for developers those coming from winform development.
ASP.NET Web Forms and MVC are two web frameworks developed by Microsoft - they are both good choices. Neither of the web frameworks are to be replaced by the other nor are there plans to have them 'merged' into a single framework. Continued support and development are done in parallel by Microsoft and neither will be 'going away'.
Each of these web frameworks offers advantages/disadvantages - some of which need to be considered when developing a web application. A web application can be developed using either technology - it might make development for a particular application easier selecting one technology versus the other and vice versa.
ASP.NET Web Forms:
Development supports state
• Gives the illusion that a web application is aware of what the user has been doing, similar to Windows applications. I.e. Makes 'wizard' functionality a little bit easier to implement. Web forms does a great job at hiding a lot of that complexity from the developer.
Rapid Application Development (RAD)
• The ability to just 'jump in' and start delivering web forms. This is disputed by some of the MVC community, but pushed by Microsoft. In the end, it comes down to the level of expertise of the developer and what they are comfortable with. The web forms model probably has less of a learning curve to less experienced developers.
Larger control toolbox
• ASP.NET Web Forms offers a much greater and more robust toolbox (web controls) whereas MVC offers a more primitive control set relying more on rich client-side controls via jQuery (Javascript).
Mature
• It's been around since 2002 and there is an abundance of information with regards to questions, problems, etc. Offers more third-party control - need to consider your existing toolkits.
ASP.NET MVC:
Separation of concerns (SoC)
• From a technical standpoint, the organization of code within MVC is very clean, organized and granular, making it easier (hopefully) for a web application to scale in terms of functionality. Promotes great design from a development standpoint.
Easier integration with client side tools (rich user interface tools)
• More than ever, web applications are increasingly becoming as rich as the applications you see on your desktops. With MVC, it gives you the ability to integrate with such toolkits (such as jQuery) with greater ease and more seamless than in Web Forms.
Search Engine Optimization (SEO) Friendly / Stateless
• URL's are more friendly to search engines (i.e. mywebapplication.com/users/ 1 - retrieve user with an ID of 1 vs mywebapplication/users/getuser.aspx (id passed in session)). Similarly, since MVC is stateless, this removes the headache of users who spawn multiple web browsers from the same window (session collisions). Along those same lines, MVC adheres to the stateless web protocol rather than 'battling' against it.
Works well with developers who need high degree of control
• Many controls in ASP.NET web forms automatically generate much of the raw HTML you see when an page is rendered. This can cause headaches for developers. With MVC, it lends itself better towards having complete control with what is rendered and there are no surprises. Even more important, is that the HTML forms typically are much smaller than the Web forms which can equate to a performance boost - something to seriously consider.
Test Driven Development (TDD)
• With MVC, you can more easily create tests for the web side of things. An additional layer of testing will provide yet another layer of defense against unexpected behavior.
Authentication, authorization, configuration, compilation and deployment are all features that are shared between the two web frameworks.
Anyone old enough to remember classic ASP will remember the nightmare of opening a page with code mixed in with html and javascript - even the smallest page was a pain to figure out what the heck it was doing. I could be wrong, and I hope I am, but MVC looks like going back to those bad old days.
When ASP.Net came along it was hailed as the savior, separating code from content and allowing us to have web designers create the html and coders work on the code behind. If we didn't want to use ViewState, we turned it off. If we didn't want to use code behind for some reason, we could place our code inside the html just like classic ASP. If we didn't want to use PostBack we redirected to another page for processing. If we didn't want to use ASP.Net controls we used standard html controls. We could even interrogate the Response object if we didn't want to use ASP.Net runat="server" on our controls.
Now someone in their great wisdom (probably someone who never programmed classic ASP) has decided it's time to go back to the days of mixing code with content and call it "separation of concerns". Sure, you can create cleaner html, but you could with classic ASP. To say "you are not programming correctly if you have too much code inside your view" is like saying "if you wrote well structured and commented code in classic ASP it is far cleaner and better than ASP.NET"
If I wanted to go back to mixing code with content I'd look at developing using PHP which has a far more mature environment for that kind of development. If there are so many problems with ASP.NET then why not fix those issues?
Last but not least the new Razor engine means it is even harder to distinguish between html and code. At least we could look for opening and closing tags i.e. <% and %> in ASP but now the only indication will be the # symbol.
It might be time to move to PHP and wait another 10 years for someone to separate code from content once again.
If you're working with other developers, such as PHP or JSP (and i'm guessing rails) - you're going to have a much easier time converting or collaborating on pages because you wont have all those 'nasty' ASP.NET events and controls everywhere.
The problem with MVC is that even for "experts" it eats up a lot of valuable time and requires lot of effort. Businesses are driven by the basic thing "Quick Solution that works" regardless of technology behind it. WebForms is a RAD technology that saves time and money. Anything that requires more time is not acceptable by businesses.
Proper AJAX, e.g. JSONResults no
partial page postback nonsense.
no viewstate +1
No renaming of the HTML IDs.
Clean HTML = no bloat and having a decent shot at rendering XHTML or standards
compliant pages.
No more generated AXD javascript.
Biggest single advantage for me would be the clear-cut separation between your Model, View, and Controller layers. It helps promote good design from the start.
I have not seen ANY advantages in MVC over ASP.Net. 10 years ago Microsoft came up with UIP (User Interface Process) as the answer to MVC. It was a flop. We did a large project (4 developers, 2 designers, 1 tester) with UIP back then and it was a sheer nightmare.
Don't just jump in to bandwagon for the sake of Hype. All of the advantages listed above are already available in Asp.Net (With more great tweaks [ New features in Asp.Net 4 ] in Asp.Net 4).
If your development team or a single developer families with Asp.Net just stick to it and make beautiful products quickly to satisfy your clients (who pays for your work hours). MVC will eat up your valuable time and produce the same results as Asp.Net :-)
Francis Shanahan,
Why do you call partial postback as "nonsense"? This is the core feature of Ajax and has been utilized very well in Atlas framework and wonderful third party controls like Telerik
I agree to your point regarding the viewstate. But if developers are careful to disable viewstate, this can greatly reduce the size of the HTML which is rendered thus the page becomes light weight.
Only HTML Server controls are renamed in ASP.NET Web Form model and not pure html controls. Whatever it may be, why are you so worried if the renaming is done? I know you want to deal with lot of javascript events on the client side but if you design your web pages smartly, you can definitely get all the id's you want
Even ASP.NET Web Forms meets XHTML Standards and I don't see any bloating. This is not a justification of why we need an MVC pattern
Again, why are you bothered with AXD Javascript? Why does it hurts you? This is not a valid justification again
So far, i am a fan of developing applications using classic ASP.NET Web forms. For eg: If you want to bind a dropdownlist or a gridview, you need a maximum of 30 minutes and not more than 20 lines of code (minimal of course). But in case of MVC, talk to the developers how pain it is.
The biggest downside of MVC is we are going back to the days of ASP. Remember the spaghetti code of mixing up Server code and HTML??? Oh my god, try to read an MVC aspx page mixed with javascript, HTML, JQuery, CSS, Server tags and what not....Any body can answer this question?
Web forms also gain from greater maturity and support from third party control providers like Telerik.
In webforms you could also render almost whole html by hand, except few tags like viewstate, eventvalidation and similar, which can be removed with PageAdapters. Nobody force you to use GridView or some other server side control that has bad html rendering output.
I would say that biggest advantage of MVC is SPEED!
Next is forced separation of concern. But it doesn't forbid you to put whole BL and DAL logic inside Controller/Action! It's just separation of view, which can be done also in webforms (MVP pattern for example). A lot of things that people mentions for mvc can be done in webforms, but with some additional effort.
Main difference is that request comes to controller, not view, and those two layers are separated, not connected via partial class like in webforms (aspx + code behind)
My 2 cents:
ASP.net forms is great for Rapid application Development and adding business value quickly. I still use it for most intranet applications.
MVC is great for Search Engine Optimization as you control the URL and the HTML to a greater extent
MVC generally produces a much leaner page - no viewstate and cleaner HTML = quick loading times
MVC easy to cache portions of the page.
-MVC is fun to write :- personal opinion ;-)
MVC lets you have more than one form on a page, A small feature I know but it is handy!
Also the MVC pattern I feel make the code easier to maintain, esp. when you revisiting it after a few months.
MVC Controller:
[HttpGet]
public ActionResult DetailList(ImportDetailSearchModel model)
{
Data.ImportDataAccess ida = new Data.ImportDataAccess();
List<Data.ImportDetailData> data = ida.GetImportDetails(model.FileId, model.FailuresOnly);
return PartialView("ImportSummaryDetailPartial", data);
}
MVC View:
<table class="sortable">
<thead>
<tr><th>Unique Id</th><th class="left">Error Type</th><th class="left">Field</th><th class="left">Message</th><th class="left">State</th></tr>
</thead>
<tbody>
#foreach (Data.ImportDetailData detail in Model)
{
<tr><th>#detail.UniqueID</th><th class="left">#detail.ErrorType</th><th class="left">#detail.FieldName</th><th class="left">#detail.Message</th><th class="left">#detail.ItemState</th></tr>
}
</tbody></table>
How hard is that? No ViewState, No BS Page life-cycle...Just pure efficient code.
I can see the only two advantages for smaller sites being:
6) RESTful urls that enables SEO.
7) No ViewState and PostBack events (and greater performance in general)
Testing for small sites is not an issue, neither are the design advantages when a site is coded properly anyway, MVC in many ways obfuscates and makes changes harder to make. I'm still deciding whether these advantages are worth it.
I can clearly see the advantage of MVC in larger multi-developer sites.
Main benefit i find is it forces the project into a more testable strcuture.
This can pretty easily be done with webforms as well (MVP pattern), but requires the developer to have an understanding of this, many dont.
Webforms and MVC are both viable tools, both excel in different areas.
I personally use web forms as we primarily develop B2B/ LOB apps.
But we always do it with an MVP pattern with wich we can achieve 95+% code coverage for our unit tests.
This also alows us to automate testing on properties of webcontrols
property value is exposed through the view eg
bool IMyView.IsAdminSectionVisible{
get{return pnlAdmin.Visible;}
get{pnlAdmin.Visible=value;}
}
)
I dont think this level of testing is as easily achived in MVC, without poluting my model.
You don't feel bad about using 'non post-back controls' anymore - and figuring how to smush them into a traditional asp.net environment.
This means that modern (free to use) javascript controls such this or this or this can all be used without that trying to fit a round peg in a square hole feel.
Modern javascript controls as well as JSON requests can be handled much easily using MVC. There we can use a lot of other mechanisms to post data from one action to another action. That's why we prefer MVC over web forms. Also we can build light weight pages.
My personal opinion is that,
Biggest dis-advantage to using ASP.Net MVC is that CODE BLOCKS mixed with HTML...
html hell for the developers who maintain it...