I just listened to the StackOverflow team's 17th podcast, and they talked so highly of ASP.NET MVC that I decided to check it out.
But first, I want to be sure it's worth it. I already created a base web application (for other developers to build on) for a project that's starting in a few days and wanted to know, based on your experience, if I should take the time to learn the basics of MVC and re-create the base web application with this model.
Are there really big pros that'd make it worthwhile?
EDIT: It's not an existing project, it's a project about to start, so if I'm going to do it it should be now...
I just found this
It does not, however, use the existing post-back model for interactions back to the server. Instead, you'll route all end-user interactions to a Controller class instead - which helps ensure clean separation of concerns and testability (it also means no viewstate or page lifecycle with MVC based views).
How would that work? No viewstate? No events?
If you are quite happy with WebForms today, then maybe ASP.NET MVC isn't for you.
I have been frustrated with WebForms for a really long time. I'm definitely not alone here. The smart-client, stateful abstraction over the web breaks down severely in complex scenarios. I happen to love HTML, Javascript, and CSS. WebForms tries to hide that from me. It also has some really complex solutions to problems that are really not that complex. Webforms is also inherently difficult to test, and while you can use MVP, it's not a great solution for a web environment...(compared to MVC).
MVC will appeal to you if...
- you want more control over your HTML
- want a seamless ajax experience like every other platform has
- want testability through-and-through
- want meaningful URLs
- HATE dealing with postback & viewstate issues
And as for the framework being Preview 5, it is quite stable, the design is mostly there, and upgrading is not difficult. I started an app on Preview 1 and have upgraded within a few hours of the newest preview being available.
It's important to keep in mind that MVC and WebForms are not competing, and one is not better than the other. They are simply different tools. Most people seem to approach MVC vs WebForms as "one must be a better hammer than the other". That is wrong. One is a hammer, the other is a screwdriver. Both are used in the process of putting things together, but have different strengths and weaknesses.
If one left you with a bad taste, you were probably trying to use a screwdriver to pound a nail. Certain problems are cumbersome with WebForms that become elegant and simple with MVC, and vice-versa.
I have used ASP.NET MVC (I even wrote a HTTPModule that lets you define the routes in web.config), and I still get a bitter taste in my mouth about it.
It seems like a giant step backwards in organization and productivity. Maybe its not for some, but I've got webforms figured out, and they present no challenge to me as far as making them maintainable.
That, and I don't endorse the current "TEST EVERYTHING" fad...
ASP.NET MVC basically allows you to separate the responsibility of different sections of the code. This enable you to test your application. You can test your Views, Routes etc. It also does speed up the application since now there is no ViewState or Postback.
BUT, there are also disadvantages. Since, you are no using WebForms you cannot use any ASP.NET control. It means if you want to create a GridView you will be running a for loop and create the table manually. If you want to use the ASP.NET Wizard in MVC then you will have to create on your own.
It is a nice framework if you are sick and tired of ASP.NET webform and want to perform everything on your own. But you need to keep in mind that would you benefit from creating all the stuff again or not?
In general I prefer Webforms framework due to the rich suite of controls and the automatic plumbing.
I would create a test site first, and see what the team thinks, but for me I wouldn't go back to WebForms after using MVC.
Some people don't like code mixed with HTML, and I can understand that, but I far prefer the flexibility over things like Page Lifecycle, rendering HTML and biggy for me - no viewstate cruft embedded in the page source.
Some people prefer MVC for better testibility, but personally most of my code is in the middle layer and easily tested anyway...
#Juan Manuel Did you ever work in classic ASP? When you had to program all of your own events and "viewstatish" items (like a dropdown recalling its selected value after form submission)?
If so, then ASP.NET MVC will not feel that awkward off the bat. I would check out Rob Conery's Awesome Series "MVC Storefront" where he has been walking through the framework and building each expected component for a storefront site. It's really impressive and easy to follow along (catching up is tough because Rob has been reall active and posted A LOT in that series).
Personally, and quite contrary to Jeff Atwood's feelings on the topic, I rather liked the webform model. It was totally different than the vbscript/classic ASP days for sure but keeping viewstate in check and writing your own CSS friendly controls was enjoyable, actually.
Then again, note that I said "liked". ASP.NET MVC is really awesome and more alike other web technologies out there. It certainly is easier to shift from ASP.NET MVC to RAILS if you like to or need to work on multiple platforms. And while, yes, it is very stable obviously (this very site), if your company disallows "beta" software of any color; implementing it into production at the this time might be an issue.
#Jonathan Holland I saw that you were voted down, but that is a VERY VALID point. I have been reading some posts around the intertubes where people seem to be confusing ASP.NET MVC the framework and MVC the pattern.
MVC in of itself is a DESIGN PATTERN. If all you are looking for is a "separation of concerns" then you can certainly achieve that with webforms. Personally, I am a big fan of the MVP pattern in a standard n-tier environment.
If you really want TOTAL control of your mark-up in the ASP.NET world, then MVC the ramework is for you.
If you are a professional ASP.NET developer, and have some time to spare on learning new stuff, I would certainly recommend that you spend some time trying out ASP.NET MVC. It may not be the solution to all your problems, and there are lots of projects that may benefit more from a traditional webform implementation, but while trying to figure out MVC you will certainly learn a lot, and it might bring up lots of ideas that you can apply on your job.
One good thing that I noticed while going through many blog posts and video tutorials while trying to develop a MVC pet-project is that most of them follow the current best practices (TDD, IoC, Dependency Injection, and to a lower extent POCO), plus a lot of JQuery to make the experience more interesting for the user, and that is stuff that I can apply on my current webform apps, and that I wasn't exposed in such depth before.
The ASP.NET MVC way of doing things is so different from webforms that it will shake up a bit your mind, and that for a developer is very good!
OTOH for a total beginner to web development I think MVC is definitely a better start because it offers a good design pattern out of the box and is closer to the way that the web really works (HTML is stateless, after all). On MVC you decide on every byte that goes back and forth on the wire (at least while you don't go crazy on html helpers). Once the guy gets that, he or she will be better equipped to move to the "artificial" facilities provided by ASP.NET webforms and server controls.
If you like to use server controls which do a lot of work for you, you will NOT like MVC because you will need to do a lot of hand coding in MVC. If you like the GridView, expect to write one yourself or use someone else's.
MVC is not for everyone, specially if you're not into unit testing the GUI part. If you're comfortable with web forms, stay with it. Web Forms 4.0 will fix some of the current shortcomings like the ID's which are automatically assigned by ASP.NET. You will have control of these in the next version.
Unless the developers you are working with are familiar with MVC pattern I wouldn't. At a minimum I'd talk with them first before making such a big change.
I'm trying to make that same decision about ASP.NET MVC, Juan Manuel. I'm now waiting for the right bite-sized project to come along with which I can experiment. If the experiment goes well--my gut says it will--then I'm going to architect my new large projects around the framework.
With ASP.NET MVC you lose the viewstate/postback model of ASP.NET Web Forms. Without that abstraction, you work much more closely with the HTML and the HTTP POST and GET commands. I believe the UI programming is somewhat in the direction of classic ASP.
With that inconvenience, comes a greater degree of control. I've very often found myself fighting the psuedo-session garbage of ASP.NET and the prospect of regaining complete control of the output HTML seems very refreshing.
It's perhaps either the best--or the worst--of both worlds.
5 Reasons You Should Take a Closer Look at ASP.NET MVC
I dont´t know ASP.NET MVC, but I am very familiar with MVC pattern. I don´t see another way to build professional applications without MVC. And it has to be MVC model 2, like Spring or Struts. By the way, how you people were building web applications without MVC? When you have a situation that some kind of validation is necessary on every request, as validating if user is authenticated, what is your solution? Some kind of include(validate.aspx) in every page?
Have you never heard of N-Tier development?
Ajax, RAD (webforms with ajax are anti-RAD very often), COMPLETE CONTROL (without developing whole bunch of code and cycles). webforms are good only to bind some grid and such and not for anything else, and one more really important thing - performance. when u get stuck into the web forms hell u will switch on MVC sooner or later.
I wouldn't recommend just making the switch on an existing project. Perhaps start a small "demo" project that the team can use to experiment with the technology and (if necessary) learn what they need to and demonstrate to management that it is worthwhile to make the switch. In the end, even the dev team might realize they aren't ready or it's not worth it.
Whatever you do, be sure to document it. Perhaps if you use a demo project, write a postmortem for future reference.
I dont´t know ASP.NET MVC, but I am very familiar with MVC pattern. I don´t see another way to build professional applications without MVC. And it has to be MVC model 2, like Spring or Struts. By the way, how you people were building web applications without MVC? When you have a situation that some kind of validation is necessary on every request, as validating if user is authenticated, what is your solution? Some kind of include(validate.aspx) in every page?
No, you shouldn't. Feel free to try it out on a new project, but a lot of people familiar with ASP.NET webforms aren't loving it yet, due to having to muck around with raw HTML + lots of different concepts + pretty slim pickings on documentation/tutorials.
Is the fact that ASP.net MVC is only in 'Preview 5' be a cause for concern when looking into it?
I know that StackOverflow was created using it, but is there a chance that Microsoft could implement significant changes to the framework before it is officially out of beta/alpha/preview release?
If you are dead set on using an MVC framework, then I would rather set out to use Castle project's one...
When that's said I personally think WebControls have a lot of advantages, like for instance being able to create event driven applications which have a stateful client and so on. Most of the arguments against WebControls are constructed because of lack of understanding the WebControl model etc. And not because they actually are truly bad...
MVC is not a Silver Bullet, especially not Microsoft MVC...
I have seen some implementation of MVC framework where for the sake of testability, someone rendered the whole HTML in code. In this case the view is also a testable code. But I said, my friend, putting HTML in code is a maintenance nightmare and he said well I like everything compiled and tested. I didn't argue, but later found that he did put this HTML into resource files and the craziness continued...
Little did he realized that the whole idea of separating View also solved the maintenance part. It outweighs the testability in some applications. We do not need to test the HTML design if we are using WYSWYG tool. WebForms are good for that reason.
I have often seen people abusing postback and viewstate and blaming it on the ASP .NET model.
Remember the best webpages are still the .HTMLs and that's where is the Power of ASP .NET MVC.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I find myself on the edge of trying out ASP.NET MVC but there is still "something" holding me back. Are you still waiting to try it, and if so, why? If you finally decided to use it, what helped you get over your hesitation?
I'm not worried about it from a technical point of view; I know the pros and cons of web forms vs ASP.NET MVC. My concerns are more on the practical side.
Will Microsoft continue to support ASP.NET MVC if they don't reach some critical threshold of developers/customers using it?
Are customers willing to try ASP.NET MVC? Have you had to convince a customer to use it? How did that go?
Are there major sites using ASP.NET MVC (besides SO)? Could you provide links if you have them?
Did you try ASP.NET MVC and found yourself regretting it? If so, what do you regret?
If you have any other concerns preventing you from using ASP.NET MVC, what are they?
If you had concerns but felt they were addressed and now use ASP.NET MVC, could you list them as well?
Will Microsoft continue to support ASP.NET MVC if they don't reach some critical threshold of developers/customers using it?
They will for sure.
Are customers willing to try ASP.NET MVC? Have you had to convince a customer to use it? How did that go?
Customers care about high quality products and price. Just convince them that Mvc will help to raise quality and lower price. Shouldn't be hard.
Are there major sites using ASP.NET MVC (besides SO)? Could you provide links if you have them?
Isn't it enough with SO? :)
Did you try ASP.NET MVC and found yourself regretting it? If so, what do you regret?
I did try and didn't regret it at all. It kills me being forced to work on web forms project again.
Go for it!
I believe ASP.NET MVC has reached that critical threshold, as evident by VS 2010 tooling, ASP.NET, MS employee blog and the extensive effort Microsoft put into the framework thus far. I don't see this framework perishing in the next decade (or two).
By customers, I assume you mean people that I build websites for? The only issue I find with ASP.NET is the hosting solutions. However, this issue is becoming moot as more affordable hosting solutions are found. But usually, if I believe in the technology and that it will work for my customer, my customer trusts me and agrees on it. The customer is also usually comforted by the fact that ASP.NET-MVC is a Microsoft product. Having a big company behind a technology is always a nice thing to have, since you can rest assured it will be supported for quite awhile with frequent updates.
ASP.NET MVC is a relatively new framework, and slow adoption of new technology is expected. But this is what I found: http://weblogs.asp.net/mikebosch/archive/2008/05/05/gallery-of-live-asp-net-mvc-sites.aspx . I think you'll see a big influx of websites using ASP.NET-MVC this year when VS 2010/.NET 4 are released with built-in support for ASP.NET MVC.
I never enjoyed developing with C#/ASP.NET more than when I started using ASP.NET-MVC. To a certain extent, ASP.NET-MVC forces you to write good code more so than WebForms due to ASP.NET-MVC inherit separation of concerns and easy customization. And the ability to control HTML output is essential, a feature that was difficult with ASP.NET-WebForms (pre 4.0).
I use MVC and hate it, especially, the front end, web form are far more better in the front end... With loads of javacript on the page, that means it is hard to maintain and take a longer time to develop and debug..
To do a very complicated page, the flexibility of MVC is limited, you will end up with using a lot of javascript control, and you know what? Different controls use different version of jquery, and they have conflict..
It is actually the javascript, and lack of UI flexibility that pulls me off, especially you are NOT working on your code
and we have more issues of browser compatability, with the new browsers coming, you are going to shoot yourself with MVC
MVC front end is very fast if your web site is not too big.. The backend of MVC is very good, it is the front end that blows it over
Why not? The rest of my team doesn't want to.
I have not yet actually tried coding up some ASP.Net MVC(looked at a few examples though) but the main thing holding us back from using it is that all of our code is currently written using Webforms.
Regarding Microsoft support ASP.Net. First Scott Guthrie, the VP of Development at MS is behind it, so that's one feather in its cap. Second its open source now so even if for some strange reason MS decides not to support it going forward you can still tweak it on your own if you need to. In addtion the MVC pattern is somethign that more and more web development platforms are using. It is a great pattern for web development and as a result I can't think of any reason MS wouldn't continue to support it.
If by customers you mean end users, honestly they shouldn't care how you implement the site. If by customers you mean consulting clients, if you can develop faster and they have the servers that can host it, I would think they would be open to it. On top of that youre MVC sites should use less bandwidth than a typical Web Forms web site (IMHO) mainly because there is a lot of additional stuff put into a Web Forms page (for example extra attributes in the HTML htat are tailored for web forms, ViewState) so that should be seen as a positive by them. Now if by customers you mean people integrating with you, then its also a plus since MVC makes it very easy to implement REST based web services (not that WFC doesn't but MVC works very nicely as well).
Hmm major sites using MVC, so far I've found a list here I also know of a number of apps at different companies where large scale MVC apps are in development. I wish I could give more detail, but unfortuantely I can't at the moment.
When I first started out with ASP.Net MVC I thought I was going to hate it. I wasn't a huge fan of Web Forms either, but MVC just felt like a step back to ASP development back before .Net came out. Then I started really getting into it and really finding the pattern is clean, concise, extensible, maintainable, and easy to pick up. Honestly I don't want to ever go back to Web Forms, and anytime I find myself doing a .Net web app I make a point of making it an MVC project.
You need to choose what's more appropriate to your product. Webforms has a few things to recommend it over mvc in some situations.
The big one is a developer working on in-house tools at small to medium shops. In these circumstances:
Large viewstates are not likely to be a problem, because your users typically have 100Mbit upload to your web server rather than a measly 128Kbit or less.
Javascript is likley to be supported by everyone
Development time matters more than widespread cross-browser compatibility or even nice design.
You're likely stuck working with inherited devs who used to do desktop/forms style development, or have a lot of churn among junior devs who don't really know web development.
All of those things together mean that webforms is still a very good fit. And let's be honest: a lot more programmers work at these small to medium in-house shops than do public internet work. So webforms isn't going anywhere.
That said, one of the big things coming up among these small shops is likely to be taking their internal tools and making them available offsite for telecommuters. In that situation, you need to start worrying more about WAN performance odd browser issues where MVC might be a better fit.
Dell is hiring masses of ASP.NET MVC developers in Texas and India for major work on many of their websites.
According to The Gu, ASP.NET MVC will have it's own product and development cycle. It is now 100% detached from ASP.NET WebForms and it's not going away.
Did you try ASP.NET MVC and found yourself regretting it? If so, what do you regret?
I do not regret trying out MVC in fact I love it. When I started it out I hated it I kept looking for the code behind file and was unsure at first how to get values out textboxes and stuff without going textbox1.Text;
Now I cringe every time I go back to webforms and wish I could write it in ASP.NET MVC because I just love how your working with html instead of using drag and drop controls that usually make your life alot harder if you got to customize them to much. I love how ASP.NET MVC likes to focus on good code like design patterns such as the Repository pattern and how to do unit test using TDD.
I have not picked up a book yet in MVC where they talked about how to make good code. I am not saying you can't write good code in Webforms but in the books and classes that I seen teach ASP.NET this never seems to be a main focus.
Like for instance I hate the datasource controls I am tutoring some people in WebForms and they love to drag a datasource in and then write their SQL statements in that datasource. Then in the code behind they use these datasorces to insert their records.
So every time they need to make a new SQL query a new datsource is dragged on and made. So now you all your logic is all mixed together. It makes it so much harder to find out whats going on, switch to different things if needed then of course it is limiting.
Something that revolves around the name "controller" can only mean problems.
I tried following the Nerddinner http://www.asp.net/mVC/ tutorial this morning. I'm comfortable in webforms, but nothing in that nerddinner tutorial made sense, just an outdated, hardcoded recipe from mvc1.0 that dosent even compile with the current mvc2.0, probably Wrox made this tutorial, only they can come up with only formating and no content.
I didn't see anything in there that was good; a bunch of hardcoded conventions I didn't need.
I certainly didn't see anything in there that would make me say I'd want to move from webforms, although this seems to be all the propaganda I read.
They put this tutorial based around wizards, on http://www.asp.net/mVC/ main page, while claiming the model is lean, all of it is generated code they don't explain, the default mvc template project has something like 15 references.
This 2 page website managed to be slow to build and to load.
Was 30 minutes in it until I realized my data model didn't match the one from the tutorial and many things that had been generated using the create controller and create view wizards were now failing.
With what I was provided in the rushed tutorial, I wasn't able to recover the project. I'll just pass until I find better documentation.
I was wondering if someone could provide me with some answers. I've been asking to swap our internal apps to an MVC architecture for quite a while now. Rails was absolutely shot-down as a toy, Struts is just too huge for the apps we do, Django's name makes these old folks nervous (oil & gas industry) but finally, finally Microsoft has come out with MVC 1.0.
Since the Powers that Be are dead-set on using Microsoft technologies, I think I may be able to convince them to move our applications to an MVC pattern. Unfortunately, I can't come up with a good reason to swap to our forms-based structure to an MVC style.
Can anyone think of justification good enough to feed to my bosses? :-)
Do you have a good reason to switch? It sounds like you don't so I am wondering if you are switching for the sake of MVC itself which I would discourage you from doing.
ASP.NET MVC is helpful when you wish to have more control over the output and lifecyle of your application. Keep in mind that in many cases this means more work for you as the developer. MVC frameworks are good for sites that are not data-entry intensive - in other words if you handle a lot of form POSTs and process data out of those forms then ASP.NET MVC will actually create more work for you.
I don't mean to sound harsh but it seem strange to me that you want to switch to ASP.NET MVC but don't really know why.
There are a number of questions that address this in different ways:
Should I pursue ASP.NET WebForms or ASP.NET MVC
How to decide which is right, WebForms or MVC when doing ASP.NET
Traditional ASP .NET vs MVC
Biggest advantage to using ASP.Net MVC vs web forms
MVC Versus Web Forms
ASP.NET vs ASP.NET MVC
I think it's not a matter of "selling" MVC, but rather of understanding it's advantages.
also, you should seriously evaluate whether migrating an existing system to MVC will be cost effective.
however, MVC has many advantages - here are some from the top of my head:
separating control, data and presentation makes your application more maintainable
easier to make changes
after a relatively short learning curve, easier for other programmers to comprehend
better design means introducing new features is easier. try adding caching, form validation, etc when everything is mixed up...
an MVC system may be more testable (and therefor can be more reliable) - it's much easier to test your controllers than to test a spaghetti of data, control and presentation code.
I think that in this case the OP is looking for a pragmatic (profitable) reason to switch over to MVC, since most companies think that way.
The biggest advantage is that it is much easier to create unit tests for ASP.NET MVC applications. A good suite of unit tests can then serve as the foundation of a Continuous Integration process.
The bottomline for the powers to be is that you can create a build in a single step, simplifying deployment, creating installers, patches etc.
Rails and Django both follow the Model View Controller (MVC) pattern so sounds like you will just be creating a load of work for yourself. Why do YOU want to switch to ASP.NET MVC?
"Struts is just too huge for the apps we do"
In what way? Struts made even simple internal applications a breeze to develop in our company, once we had learned how it worked (which was quite quick). A few JSPs, a few Actions, backend database access done in JDBC via some simple DAOs, bundle it all up in a war with ant/maven and deploy. Done.
Also, fyi, keep Joel's advice in mind (Things You Should Never Do, Part I): avoid rewrite the code from scratch.
This is a difficult question to ask because it's so wide ranging.
Does anybody know of a scoring system of questions that would aid in choosing between a WebForms and MVC application at the start of a project?
e.g. Is TDD an important part of this project? (If yes score 1 for MVC and 0 for WebForms)
I would consider the following:
Current Skill Set of the team. If you have a large team that aren't going to pick up MVC quickly but are comfortable with Web Forms I'd stick with Web Forms
What level of control do you need? MVC gives you more control but that also means you'll be doing a lot of extra things your self. WebForms gives you a lot less control but there are a lot more things in the box. If being able to control the HTML output is important to you than maybe MVC is a better fit.
Will you need third party integration? There isn't a whole lot of 3rd party control support for MVC however there is a ton of support for webforms. Getting a nice grid in webforms is simple, however you'll be writing a lot of your own code in MVC to solve that problem
As you mentioned, is TDD desirable?
State management is a lot easier in web forms
I have a single question test (disclaimer: it's far from perfect, but does the job a lot of time in making you lean toward each of the technologies):
Is your application more form oriented (e.g. intranet stuff or something) or you are building an Internet-facing Web site (e.g. StackOverflow). In the first case, I'd probably go with Web forms. The latter case is probably better satisfied by ASP.NET MVC.
Another thing: these two are not the only paradigms out there. Before MVC days, I've done several projects by building HTTP Handlers that do the routing and other stuff that MVC does. You could also strip the Web form part of ASP.NET and just use non-server-form Web controls (while you'd do it in a standard Web forms project, I can hardly call this style ASP.NET Web forms).
Unless you are working on a very data centric app and need server controls with databinding and viewstate, I would go with MVC.
I haven't made anything serious in web form since MVC preview 2. MVC is much better with regard to design patterns and best practices.
And yes IMO TDD is very important and gives more than 1 point to MVC.
Usually, the decision to use WebForms or MVC boils down to controls. If you are going to be using a lot of server-side controls, then WebForms is for you. If you don't have that burden then MVC, at least in my opinion, is much cleaner, and more testable.
After using both of them the way I decide now is: Do I need to use server controls? If I don't then I default to MVC.
If you were stuck with WebForms for some reason then you could implement the MVP (Model-View-Presenter) pattern to separate the view from the logic and have some hope of unit-testing the codebehind.
I have seen the ASP.NET community buzzing about MVC. I know the basics of its origin, and that there are many sites (unless I am mistaken, stack overflow itself) based on ASP.NET MVC.
From everything I have heard and read about MVC it seems to be the future of ASP.NET development. But since I don't usually dabble in .NET web development I am left wondering the following: when is it appropriate to use MVC and when is it not, and why? Examples of great (and terrible) use of MVC would be fascinating.
Though I realize there are other implementations of MVC view other languages like RoR I am more interested on its impact for .NET programmers.
If this has already been gone over, my apologies!
Here are my 2 cents about MVC for web applications. For the sort of GUI apps for which MVC was originally intended, "listener" code was required, so that the UI could be updated when events altered the model data.
In MVC for the web this is unnecessary, you get your listener for free: the web server, and the HTTP request IS the event. So really MVC for the web should be even simpler. Indeed, it could be boiled down to the Mediator pattern, where the Controller mediates between the model and the view.
There are two things that there is a lot of confusion about. Regardless of conventional "wisdom":
Frameworks != MVC
Database Data != "Model"
"Full stack" web development frameworks typically add lots of features, and may or may not be MVC-oriented at their core. One of the features many frameworks add is database access or object relational mapping functionality, and because frameworks and MVC get confused, subsequently database data and the model facet of MVC also get confused. The model can generally be viewed as the underlying data for the application, but it does NOT have to come from a database. A good example might be a wiki, where the underlying model/data consists of file revision data, for instance, from RCS.
Hope this helps and I'm sure others will have plenty to add.
I would say one very compelling scenario to use MVC is if you have a group of experienced .NET developers who dont have experience with WebForms.
Coming from that situation myself (very little web experience) I found it I was much more productive and comfortable using MVC over WebForms.
I found it very hard to pickup WebForms due to the aforementioned abstraction - (I think proof of WebForms complexity is I have never met anyone who I would consider a WebForms "guru" i.e. knows the Page Lifecycle off by heart/Data Binding back-to-front etc.).
Using MVC actually allowed me to use my .NET and software experience without needing to heavily invest in learning the WebForms framework. Not only that but I got a much better understanding of HTTP, and this I think would allow higher quality solutions.
IMHO MVC allows you to factor code much better than WebForms, so I think developers with lots of "patterns" experience will be more comfortable in MVC.
ASP.NET MVC isn't the future of ASP.NET development it is just a new way of developing websites with ASP.NET. Microsoft have made it clear they will continue supporting and improving both WebForms and MVC in the future.
I cannot think of any websites, were it would not be appropriate to use MVC. You could also argue the same for WebForms.
Whether you choose one over the other is a personal choice, and would depend on the development team's experience and preferences.
I personally would never go back to WebForms development after using MVC on several big projects. WebForms in my opinion places an unnecessary abstraction layer over http and html. For quick prototypes you can get something cobbled together quicker with WebForms, but after that the complication of the abstraction makes things harder rather than easier. The only compelling reason to use WebForms in my opinion is the rich level of 3rd party controls that are currently available. But you can mix WebForms and MVC, so its easy enough to get the best of both worlds.
I work in a shop that has both ASP.NET and MVC applications. I think originally I was biased toward web forms because I worked with them from several years, but after working on a few MVC projects I prefer it.
Something to consider, however, is that if you have a team of experienced web form developers initial progress in an MVC application will be a slower because of the learning curve, so if the timeline for a project is very tight it might not be the best time to transition.
Aside from that I can't think of any situations where I'd prefer web forms over MVC at this point.
Based on my own experience, I can tell you that if you don't have any Winforms or Webforms background, you may feel more comfortable under the MVC umbrella because you are not "expecting" anything from the ASP.NET Webforms world.
On the other side, as a recommendation, I encourage you to check out other MVC frameworks like Django or RoR that are more mature to "be water" on the MVC way of thinking. I'm happy with ASP.NET MVC but looking other solutions helps you to understand better the paradigm behind the framework.
As someone with some winforms and client applications experience - is it worth going back and learning the way traditional ASP .NET pages work, or is it okay with moving straight into ASP .NET MVC?
I'm kind of looking for pitfalls or traps in my knowledge of general C#, that I won't know from the screencast series and things on the ASP .NET site.
Here is the great thing about MVC. It works closer to the base of the framework than normal ASP.NET Web Forms. So by using MVC and understanding it, you will have a better understanding of how WebForms work. The problem with WebForms is there is a lot of magic and about 6 years of trying to make the Web work like Windows Forms, so you have the control tree hierarchy and everything translated to the Web. With MVC you get the core with out the WinForm influence.
So start with MVC, and you will easily be able to move in to WebForms if needed.
I agree with Nick: MVC is much closer to the real web paradigm and by using it you'll be confronted with how your website really works. WebForms astracts most of these things away from you and, coming from a PHP background, I found it really anti-intuitive.
I suggest you directly jump to MVC and skip WebForms. As said, you'll be able to get back to it if needed.
ASP.Net Webforms is a completely different abstraction over the base framework than ASP.NET MVC. With MVC you've got more control over what happens under the covers than with ASP.NET Webforms.
In my opinion learning different ways to do things will usually make you a better programmer but in this case there might be better things to learn.
ASP.NET MVC is for developers who desire to decouple the client code from the server code. I have wanted to write JavaScript, XHTML, CSS clients that can move from server to server (without regard to server technology). Clients are time-consuming to fit and finish so you would want to use them (and sub-components) for as many servers as possible. Also this decoupling allows your server to support any client technology that supports HTTP and angle-brackets (and/or JSON) like WPF/Silverlight. Without ASP.NET MVC you were forced into a hostile relationship with the entire ASP.NET team---but Scott Guthrie is a cool dude and brings MVC to the table after years of his predecessors (and perhaps Scott himself) almost totally focused on getting Windows Forms programmers to write web applications.
Before ASP.NET MVC, I built ASP.NET applications largely based on ASHX files---HTTP handlers. I can assure you that no "real" Microsoft shop would encourage this behavior. It is easier from a (wise) management perspective to dictate that all your developers use the vendor-recommended way of using the vendor's tools. So IT shops that are one or two years behind will require you to know the pre-MVC way of doing things. This also comes in handy when you have a "legacy" system to maintain.
But, for the green field, it's MVC all the way!
It depends on your motivations. If you're going to sell yourself as an ASP.NET developer, you will need both.
If this is just for your own pleasure, then go to MVC.
My personal feeling is that webforms will be around for quite a few years more. So many people have time and energy invested in them. However, I think people will slowly (or maybe not so slowly!) migrate. Webforms was always just a way to get drag-and-drop VB4 morts to think about web development. It kindof worked but it does take away alot of control.
IMO, there are more pitfalls in normal web forms scenarios than with just MVC. Viewstate and databinding can be tricky at times.
But for MVC, it's just plain simple form post/render things old-school way. Not that it is bad, it is just different, and cleaner too.
I can't really speak technically about MVC vs "traditional" as I have only used the traditional model so far. From what I have read though, I don't think one is vastly superior to the other. I think once you "get it", you can be very productive in both.
Practically though, I would take into consideration that most books, code samples and existing applications out there are written for the "traditional" way. You have more help available and your skills will be more useful for employers with existing applications written in the "traditional" way.
If you don't know how or haven't has experience with raw level web request / response and raw html/css rendering then MVC will would be good place to start.
You will then better understand the pros and cons of both webforms and mvc. They will both be around in the future as the both address different needs.
Though I will say webforms is a highly misused and abused platform.
So much of the "look no code" rubbish gives all who use it a bad name.
Put in the time to understand it and use it properly you'll find its a very extensible and robust platform.