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.
Related
I am not starting an argumentative discussion here and this post is not about career development, but from the commercial point of view:
If a company was using ASP.Net MVC as a main methodology to build their web sites and application.
However, ASP.Net MVC takes more time to show a functional application than ASP.Net Web Forms, for example, building domain models would take some time which obviously can't be represented on a UI at that current stage.
My question is, if a client wants to see a functional demo application (just a proof of concept) so he knows that the company he is dealing with is professional and capable of doing that. Would it be better to do that demo in ASP.Net Web Forms only to show the client, and then work on the real application using ASP.Net MVC? If not, what are the (quick) alternatives?, I mean, if we tell the client to wait till we have a working demo (by ASP.Net MVC) we may lose the client and the whole project opportunity.
WebForms being faster than MVC is a myth:
You are not required to have a domain model, just something that represents your database tables. This is the same in WebForms unless you are using SqlDataSource's.
The code in your !IsPostBack or btnSubmit_OnSubmit is almost identical to the HttpPost controller actions. Except with MVC you don't have to write left to write object.FirstName = txtFirstName.Text when you understand how UpdateModel works.
UI is UI. If you know HTML/CSS creating the UI is just as easy. Almost easier in MVC because you don't have to set control properties any longer and all UI can be done in one place.
Fast MVC comes from understanding how to get the most bang from your buck using EditorFor, DisplayFor templates. You'll need to know and understand how to customize your Object.ascx file. With this technique under your belt you won't have to create forms by hand anymore. 2 projects ago we had a site with 100% autogenerated forms. Change a class, change a form. Done!
Another helpful MVC tool is the DataAnnotations attributes. Validation made easy. Customizing these is really easy too. Just create your own ModelMetaDataProvider and starting expanding the validations your application can handle.
The only part of MVC that is slower is displaying a grid. MVC 3 already has a useful grid tool and MVCContrib has had a grid tool out for a year now. I ended up rolling my own, its very simple actually, loop through properties, write <td />'s. < 200 lines of code. This isn't really a benefit to WebForms either. To use WebForms grid components means giving up a lot of quality using ObjectDataSources and the like.
To summarize fast MVC comes from these different techniques:
Object.ascx
ModelMetadataProviders
UpdateModel
DataAnnotations
If you are more advanced and know ORMS like EntityFramework and how to use Automapper your probably going to be even faster.
You can get a demo up and running very quickly in MVC. I could put one together much quicker than with WebForms, and I am familiar with both.
The reliance on convention in MCV will help a lot, binding is based on the names of objects.
If i was creating a quick demo, i would just create a bunch of ViewModels with static data in them, different button clicks etc will just bind one of these ViewModels to the page.
Turbo Fast!
I build prototypes in excel. No logic, no code. just basically screenshots to show the user that we are communicating the same ideas. Create a worksheet for each "View" or screen you need to show. Client's usually only care how "pretty" an application looks vs does it work right.
This also is a benefit as you can include more non-technical users in the prototyping process, since most are used to excel. I can send you an example and the finished production web application, if seeing is believing. I personally learn best by example.
And to your post where you wrote...
I mean, if we tell the client to wait till we have a working demo (by ASP.Net MVC) we may lose the client and the whole project opportunity.
They need to have their expectations adjusted and managed. A lot of bad development has been done quickly over the years, which makes client's ask questions like "Bob did it in 1 hour'. To that I say, you can either have a lousy project fast, that you have to constantly duct tape or a well thought out and well written project that will only need to be enhanced as Bus Reqs change
I think the answer is obvious: use whichever you think makes you faster. There's no point in using MVC if you are faster in WebForms. Especially since this is for a throw-away demo.
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.
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.
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.