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.
Related
I'm a junior programmer, i do not get the concept of MVC! My method of coding is seperating my application design into 3 layers:
Presentation Layer
Business Layer
Data Access Layer
I find it very practical to a junior developer or at least to me, so i do not really
get the point of MVC since i believe MVC just tries to separate logic from UI. Right?
I'm confused can you please give any advice!
Any help will appreciated...
I decided to have this book to help me have a better idea on code design:
http://www.amazon.com/Professional-ASP-NET-Design-Patterns-Millett/dp/0470292784/ref=sr_1_1?ie=UTF8&qid=1292836936&sr=8-1
Note: i also decided to start learning about TDD.
QUESTION:
Is breaking my code design into 3 layers (presentation, dal and business) meets MVC concept?
i was quite a late 'convert' to mvc, after having been both a classic asp and webforms developer for over 10 years. however, about 18 months ago, a project came along that our management team decided would be a good self contained project to trial mvc on. I was tasked with managing the project. I'll admit that i was VERY sceptical as we had a large collaterol of components built for webforms as well as our own 'mini framework' for webforms projects.
imagine my surprise when I slowly found that being closer to the metal with the mvc paradigm was actually a more productive process. soon, i even began to question whether to go webforms or mvc on other new projects that were starting up. the beauty was that our webforms projects used the 3 layers approach that you mention and for us, it was quite easy to switch out the webforms portion and slot our BLL/DAL into place and use within the mvc project.
The long and the short of it is that it'll take time to get up to speed on the concepts of mvc but thankfully, there are many great books and tutorials out there:
http://nerddinner.codeplex.com/
http://blog.stevensanderson.com/
http://www.amazon.com/ASP-NET-Framework-Second-Experts-Voice/dp/1430228865/ref=pd_sim_b_2
i'd recommend the steven sanderson book, if it's the only one you ever look at. it ties together a very comprehensive walk thro on many core concepts, leading to a very detailed understanding of 'how it all works' by the end of the piece.
In short, no, designing with 3 layers doesn't = mvc. however, if you're worried about losing the knowledge and core functionality that you've built in your 3 layer approach, you needn't be. mvc and the BLL/DAL can work together just wonderfully. there is a fear when moving from webforms that you lose all the previous dpmain logic - in short, they happily merge/co-exist and it's entirely possible to still have part of the team working on the business logic whilst another part deals exclusively with the mvc implementation of that.
I was going to drone on about the excellent jquery integration - but that's a tale for another day :)
I suggest you start by viewing this video: MVC or Webforms - Choosing the Right Programming Model.
If you decide to go for MVC, then simply take a look at all the tutorials here: http://www.asp.net/mvc.
Since you mentioned TDD, I think this might be the best reason to go for MVC rather than web forms.
MVC is much better suited to TDD since it allows interaction to be tested with unit testing framework. I think this book is a good start on TDD with MVC
MVC can mean almost anything depending on what scenario you're talking about.
In ASP.NET (not MVC), you make pages that basically contain both the logic and the view for it. When a an aspx page loads, the "code-behind" (logic) is executed and binds data to the view to display it. This is repeated, all the time.
In ASP.NET MVC, you define controllers which, in turn, contain "actions" (methods) that usually build up objects called view models. The view models contain the data that the view will use to display. This is in a way equivalent to data binding in ASP.NET.
ASP.NET MVC uses web forms for its views by default but this can relatively easily be changed to another view engine.
So to answer your final question, ASP.NET MVC is a reasonable choice if you want to split the application up into "layers". ASP.NET MVC is also a good choice if you want good testability as that is one of the main problems with old ASP.NET.
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.
Here's my particular situation...
I have a decent amount of experience with webforms, and I must say, a lot of it has been pretty frustrating. I like that there are lots of built-in controls, but then I discover that they don't quite do what I want, out of the box. I end up rolling my own controls (that inherit from the built-in controls), such as GridViewThatCanSortItself or GridViewThatHasASelectionColumn (these may not have been the actual names, but you get the idea). I've often wondered, while struggling mightily to build such classes, whether figuring out the often convoluted event model was worth it. My attempts to use css to style things have been frustrating as well. There are some ASP.NET controls that will result in one html tag for one set of attributes and a different tag with another set of attributes. You don't realize this until you notice your css only works half the time.
So, my brain starts to wonder, could ASP.NET MVC be the answer? Reading some of the posts on SO has basically given me the impression that, while webforms definitely has its issues, I'd only be trading one set of problems for another. It even seems like Microsoft is trying to talk me out of it:
Quote from the asp.net site (http://www.asp.net/learn/mvc/tutorial-01-cs.aspx)
ASP.NET MVC...works well for Web applications that are supported by large teams of developers and Web designers who need a high degree of control over the application behavior.
That is really not me. Most of my projects are relatively small, and I'm usually the only programmer. I sometimes need to create very custom or unusual UI's, but I definitely don't have a team of programmers who can build components for me.
There is also the issue of javascript. I have a definite working knowledge of html and css, but I can't say the same for javascript. As clumsy and bloated as they are, I've been able to do some smooth enough looking things with UpdatePanels. I'm not sure how much time I'd need to spend just learning the javascript to be able to handle even simple AJAX scenarios in ASP.NET MVC.
I'm about to start working on a relatively simple and small web app, so now would be the time to take the plunge if I'm going to take the plunge. This app will use a SQL Server Express (2005 or 2008) back-end, and I'm thinking of also trying out SqlMetal as an ORM solution. So, that's already one thing I'm going to have to learn, although I at least have experience with--and really like--LinqToXml and LinqToObject. The pages of the web app will have some data grids (some with link columns), input boxes, labels, drop-down lists, check boxes, radio buttons, and submit/action buttons. I don't foresee anything more complicated than that. There will be about six or seven pages total.
Questions:
Given my experience, how painful will it be to learn ASP.NET MVC? Will it be worth it?
I've read some earlier questions comparing webforms to MVC, so I'm curious, How has MVC evolved over the past year or so? Is there anything new that would make the learning curve less steep?
Do I literally have to write code to generate all html by hand or are there code/libraries readily available in the community to assist with the process? (I know I read something about "html helpers"--that may be what I'm asking about here.)
Any other advice?
Update
Another question that occurred to me: Is the transition from ASP.NET webforms to MVC anything like going from standard WPF (using code-behind) to MVVM? I found learning WPF itself to be pretty challenging (and I still couldn't say I really get everything about it), but learning to work with WPF using the MVVM pattern was a relatively painless transition. So, I'm wondering how similar a jump it is to go from webforms to ASP.NET MVC.
My advice is to work through the Nerd Dinner Tutorial from the first chapter of Professional ASP.NET MVC (and then buy the whole book, it's great) to get a feel for how it fits together and how it works for you. This covers most of what you are concerned about above.
You will have to get your hands dirty with regards working with raw HTML but this is no way near as terrifying as it may sound. Especially as you're having issues where Web Forms takes control.
Yes, Asp.Net Mvc might be a solution for your problems.
I would highly recommend you not to rush
(without better knowledge you will end up at disappointment).
But in either way - it definitely be worth it. You will learn a lot.
Start with bunch of sample applications while reading some books (start with Sanderson`s, continue with Mvc In Action). Familiarize yourself with asp.net mvc. It demands different way of thinking about web development you are likely used to. And don't be afraid of 3rd party tools - get used to them because asp.net mvc does not focus on 'ready 2 drop through designer and use' solutions and lack of super cool and shiny (with awful js/html underneath) controls at start really frightens.
After few weeks of playing around with it - you will actually be able to answer this question yourself.
And that's the one and only answer that's worth something.
Personally - i prefer asp.net mvc framework and don't want to go back despite that in some cases it does take more work (i.e. - implementation of custom pagination (which can be easily made way more sophisticated than one that pagination control provides)).
Framework demands better knowledge of OOP, architecture and design knowledge, good sense of code tidiness because there is much less 'signs' that provide direction of one and correct way of doing things - they must be figured out in most cases by yourself. So - it is easier to drown in your own sh*t, html tag soup etc. if you are unsure and/or don't know what you are doing.
I kind a disagree with that statement about large developer team. This is where knowledge about OOP, 'convention over configuration' and extensability of Mvc framework comes into play. As i see it - it's way more easier (this is really really subjective) to write code that's reusable. And with features like templates (in mvc version no2) count of code lines is reduced drastically.
And learn javascript. You are missing a lot. Play around with jQuery if you haven't done that yet (greatly reduces cross-browser compability problems). Firebug plugin for FireFox is a great aid at this (for debugging purposes). AJAX`ifying your mvc website might seem awkward at first (there's a great tips in 'Mvc in action' book about this topic like form hijacking that can be used to achieve so called progressive enchancement with AJAX), but once you get used to JS - it feels superb. One thing to mention - JS is quite sharp tool (if you don't drop what you know about development in .NET environment and don't use it as it's supposed to). It's easy to screw up JS code base in no time.
Another thing - there's a bunch of myths about mvc framework along those who have touched only web forms.
It is not hard to work with raw html.
It is not hard to read form values (binding mechanism is excellent and easily customizable/extensible).
I'm sure there are more. Just can't remember at the moment. :)
#DanThMan, I had the same reservations you did when I first took a look at the framework but having worked with it now for some time there is no way, given the choice, that you'd get me back into WebForms.
I also write, from time to time, small applications where I am the only developer and I thank God I stuck to the MVC framework and took the time to really learn it.
In my mind it has made programming fun again and I can now maintain sites quickly and easily which is a first.
For my money this is the way to go but it's a steep learning curve and you need time to get to really understand it. If you have the time I'd say go for it.
There's some good answers here and some good ones in other threads as well. I'll take a stab at a question that hasn't really been addressed yet.
How has MVC evolved over the past year
or so? Is there anything new that
would make the learning curve less
steep?
I made a conscious switch to MVC about 8 months ago and haven't looked back. Version 1 was stable and I began to use it on a couple of sites with the help of a couple of books and the internet of course. Resources were good back then but since I switched things have really blown up in a good way.
There are a couple of books out there for version 1 that are top notch (Steve Sanderson's - Pro ASP.NET MVC Framework and the Nerd Dinner book come to mind). And there is definitely asp.net MVC blood in the water so I imagine there will be some great version 2 books down the line.
The developer community, especially here, is excellent and it's getting better. "asp.net-mvc" is currently the 16th most used tag on this site and often has a very high amount of views per question. As of today I have yet to have a question that hasn't been answered. There's a lot of smart people looking at the MVC questions who are willing to help.
The contrib library over at codeplex is also getting better and getting some nice participation. They've done a great job of filling in some holes that version 1 has left. I can only think that this will continue to get stronger as MVC gets older.
The new features for version 2 are in my opinion awesome. I won't name my favorites as they won't mean much to you if you haven't played with MVC much but just know that the development team has listened and included a number of great enhancements for the new version. They are very actively seeking feedback and always looking for improvements. Do not expect this change anytime soon. (One day I called up Microsoft and said "Shorten '[AcceptVerb(Http.Post)]' to '[HttpPost]'" and bam, Mvc 2 was my idea.)
The point I'm trying to make is: since I made the switch I've seen things get better and better. I'm incredibly happy with my decision and I'm excited for the future of this project. Version 1 is good, Version 2 is better and I can't wait to see what 3, 4, and 5 ... hold.
And I'll leave you with this: I've now converted a number of friends from WebForms to MVC. Every single one of the them is glad they made the switch and the ones that work with all aspects of an application (C# code, html, css, javascript, data access, unit testing, etc) will never go back and are loving the asp.net MVC life.
Given my experience, how painful will it be to learn ASP.NET MVC? Will it be worth it?
Yes and yes. It will be painful and it will be worth it and here's why. You will be a better programmer for it and your skills will more easily transfer to other platforms. MVC is a very common pattern that you will find over and over again in just about every popular language.
You will be working more closely with html, javascript, and css, but that's web programming and you're better off biting the bullet sooner than later.
having worked my last few projects (prior to embracing mvc) using my own controls being rolled via the HtmlTextWriter, I actually found th transition quite straightfwd. i have to say tho', i did put it off until v1.0 was well and truly 'out there' and only made strides from aug/sept 09. i'm glad i got into it as the main reasons i had been using the HtmlTextWriter in webforms was to overcome some of the basic issues of class names and id's when using jquery. i'm not going to say that v1 is a silver bullet but it certainly just works in tandem with my mindset at the moment. as for literature, i too read the sanserson and nerd dinner books and took plenty away from them. at the same time, i also got into subsonic v3 and found a fair amount of tips on rob's site to get me going.
i seriously can't imagine having to go 'back' to the webforms paradigm as i had been looking for a way to drop the page lifecycle and controls bloat for such a long time (i had even looked at php framewirks at one point as a way out of the webforms dilema - kohana is a great little php framework).
anyway, just my scottish 2 pence worth...
merry xmas all and a happy 2010
jimi
Some developers seem to have an aversion to component-oriented programming. For others, it feels natural. If you find yourself constantly fighting the standard components, then it's easy enough to roll your own from scratch--which you would basically end up doing in MVC anyway. If you find yourself fighting the unit test model with web forms, you will find things easier with MVC.
However, MVC isn't a cure-all; there's a lot to learn. Some apps will be less complex than with web forms, and some will be much more complex.
I've found that web forms don't really gel with many developers until they deeply understand the page life cycle and use of ViewState. Until that point, there seems to be a lot of trial and error -- but it's easier to learn that than MVC with IOC, etc. As far as customizing output, it's often easier to use control adapters than to subclass the control. In case it helps, I walk through these issues from the web forms side in my book: Ultra-Fast ASP.NET.
In the end, I think it's partly a mindset thing, and which model fits the way you solve problems and think about your application better.
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.
is there any particular website that would make sense to use MVC versus webforms.
what would be the decision process in deciding between these options?
There is a lot of enthusiasm around MVC right now, but if you are starting a new dev project right now I'd still recommend that you carefully consider before jumping on the MVC train just yet.
For most dev teams on any non-trivial project, there are some serious considerations. Here are the ones I find most relevant:
MVC requires much more skill from your developers. They will need significant expertise in the inner workings of HTML/CSS as well as a good understanding of how HTTP works. For the client side code they will need strong javascript and JQuery skills, and on the server side an advanced grasp of OO principals. And if you plan to get the most from MVC, experience with unit testing and mocking frameworks too.
The MVC 1.x framework currently doesn't get much in the way of RAD features from Visual Studio. You get a text editor and intellisense, but that's about it. No wizards, no drag-n-drop components, no property editors, etc. While this isn't really that bad, it does often mean that building non-trivial UIs will take significantly longer, especially for less experienced developers.
MVC is very new, and so code samples, tutorials, and sample apps are very hard to come by and tend to be very limited in scope. Documentation is also a bit thin at present.
Perhaps the biggest drawback to the MVC framework is the lack of an established and mature 3rd party market around it. With web forms there are tons of very advanced UI suites and components on the market and tons of open source projects you can borrow from.
For many apps, especially business apps the lack of 3rd party reporting, charting, and advaned grid controls for the MVC framework alone should be a major concern.
MVC is fantastic, and I highly recommend it if you are in a position where you can use it. But there are real costs and risks for any significantly complex project that may keep you on web forms for a while longer.
I do expect that the next major version of MVC will probably address many of those issues, especially with the lack of RAD features. I also expect that the enthusiasm around MVC will bring a lot of 3rd party support to the platform too. But it will take some time for all that to get well established.
I wouldn't say a type of website would be better for either to but more or less the needs of a website.
If you need a website that's can be thrown together very quick without a large amount of code and you don't care about HTML markup. Than WebForms is the way to go.
If you're a control freak and you want control over everything that's happening and the markup being generated. Than MVC is probably for you.
MVC is less of an abstraction of the HTTP model meaning a lot less is done for you. It doesn't hold state like WebForms' ViewState.
I spent the last 4 weeks reading the available material on MVC and doing the various videos and tutorials. Today I started working on an actual application (with a client awaiting to see results some time soon). I agree with the previous answers (an awful lot to learn, many many new concepts, little in lieu of 3rd party components). Still I am glad I have spent the time learning mvc.
- You have to overcome your fear of row html/css/jscript which are hidden with webforms. It takes time to get used to the html tags. Once you do you will find out about the possibilities available. You will unlikely miss tags.
- If you have no experience using unit tests, then I think that mvc provides for a great introduction into the possibilities that come with unit testing.
- OO is much more present and "obvious" within mvc.
- Separation of concerns is possible and natural. You will not miss mixing gui and business logic in an aspx.cs file.
- No more page_load (and the n different stages). If you never quite liked asp.net's databinding, you will love mvc. I am happy not to have to do it ever again!
Cons:
- It is slow. At the beginning it is very slow. Things that take little time in webforms, can take a lot of time with mvc.
- Not having pages any longer is also a massive change. But once you "internalize" this (time...), you will not miss the pages.
- An O/R Mappers is also needed. One more thing to learn.
- There is a lot to learn and get used to, should you be interested in getting the most out of the framework. MVC is only half-mvc without unit testing. Unit testing without a mocking framework is not really possible, so you must learn that too. By the time you think you are half-way through with unit testing, you see the need to automate parts of your work, nant must be learned as well. It is just endless.... But again, once you start using these technologies you will wonder how you ever managed without.
The decision process for me is pretty simple. All new development will be done with ASP.NET MVC. Existing sites that need minor modifications will continue to be WebForms. Existing sites that need major modifications will be candidates to move to MVC.
The basic reason that I'm making the switch has to do with testability and design. IMO MVC web sites are significantly more testable. I can test everything but the view logic with unit tests and, by using and testing HtmlHelper extensions I can even test a fair amount of view logic. With WebForms I had to jump through lots of hoops to test codebehind and as a result left a lot of the app for manual testing.
I also feel that the architecture is simply better from a design standpoint. Because of the clear separation of concerns it's less tempting to insert business logic in the wrong place (e.g., the view). It makes conceptualizing and understanding the application much easier. I'm also able to reuse even view code with less effort because I don't have extraneous bits of logic from other layers hanging around to get in the way.
The only real downside I see at present is that it's not as mature and you don't already have as many reusable components built for it. I expect that to change, though, over time. Also, even though it is possible to intermix MVC with WebForms, I don't see retrofitting existing apps as a viable alternative unless there is significant other work to be done. Again, just my opinion, but I would rather start from scratch with MVC than try and get an existing app to work with it. I suppose it would depend on the size of the app, but anything with any significant number of pages is going to have a lot of routing exceptions.