When to use ASP.NET MVC vs. ASP.NET Web Forms? - asp.net

One of the common questions asked regarding ASP.NET MVC is why should you use it over ASP.NET Web Forms? The answer generally includes ViewState and clean URLs, amongst others. Towards the end you'll find a blurb about using the right tool for the job and that they serve different purposes. However, I don't believe I've ever seen what those purposes are. So, when would you actually choose ASP.NET MVC over ASP.NET Web Forms, or ASP.NET Web Forms over ASP.NET MVC?

You don't choose ASP.Net MVC over ASP.Net, because ASP.Net MVC still is ASP.Net. You do choose ASP.Net MVC or ASP.Net Web Forms, and there are lots of good reasons to do that:
Easier to get control over your HTML
Easier to do unit testing
Few "Gotchas"
On the other hand, Web Forms do have a few points in their favor:
Easy to put simple CRUD/business apps together extremely fast
Hard to beat ViewState performance in local LAN environment
Easy to learn forms paradigm
The result is that if you're building business apps in a corporate LAN environment (which honestly is still most web developers), Web Forms is really great. In that sense Microsoft really knows their market. But if you're building an app for the public internet, you might want MVC so you can test thoroughly and be sure your pages aren't bloated with unnecessary ViewState or JavaScript data.
Additionally, something that has changed over the last several years is that even many corporate intranet applications now need to support home/remote use, making MVC more attractive to that crowd than it had been.

Use MVC if all your team members are skilled enough to manage "control over HTML", otherwise your code will turn into a tag soup.
In other words
bool useMvc = true;
foreach (TeamMember member in team.Members)
{
useMvc = useMvc && member.IsSkilled;
}

http://weblogs.asp.net/shijuvarghese/archive/2008/07/09/asp-net-mvc-vs-asp-net-web-form.aspx
check that blog !
Bottom line "separation of concerns"

I'll give you a couple purposes, with clear advantages.
If your purpose is a public facing website that will be banking on traffic, use MVC. It is optimal for search engine optimization.
If your purpose is an enterprise web-application that acts like a desktop app, I would lean towards web forms, since state management and compartmentalization of your resources into underlying server controls offers huge advantages if used correctly.

The biggest problems facing developers is managing complexity and keeping code "clean". MVC gives the developer the reins to leverage OOP to tuck away complexity and make code easy on the eyes.
Webforms will be faster to develop in the short term, but it doesn't lend itself to long term sustainability in terms of maintenance and growth.

I've worked with Web forms for 13 years and MVC for 2 years now and when I started with MVC, I had similar questions. Here are my takeaways.
Most importantly: ASP.NET's latest release is 4.6 and they were moving to ASP.NET 5.0, but MS abandoned that for ASP.NET Core, which no longer supports Web Forms (or even VB.NET). So, that alone might give you your answer when deciding what rabbit hole to go down.
That being said:
MVC I'm finding, once you get the hang of it, is WAY easier for dealing with basic forms and any sort of simple "Model", aka tables with a very simple, straight-forward set of relationships such as orders that have tables that link to users, products, etc. Once you start getting into some more complicated relationships and need to return lots of conditional sets of results, rely on parameters, have complicated stored procedures... then Web Forms is much better for dealing with this. If you don't have to deal with this level of complication, MVC makes development SO MUCH faster, especially with dealing with an approach where you already have the DB because it creates so much of the code and validation for you already
If you're not very experienced with database design, MVC does the work for you. It can literally build the database for you.
MVC doesn't have a lot of the built in controls that Web Forms does (Gridviews, FormViews, Sitemaps, Paged lists). Everything has to be written from scratch, but luckily a lot of people have already invented that stuff for you in NuGet which you can just download into your project
MVC relies heavily on the structure of your URL. The path, the querystring, etc. If you find your application needing to do a lot of form POSTing instead of GET-ting, you're going to have to do a lot of tweaking or AJAX posting. If you have a set URL that can't change, it can be a pain. It's doable, but just a little tricker (or you can just use Angular instead).
MVC has no Viewstate. If you need to hide variables from post to post and persist them, it's a little difficult. MVC Does have things like ViewBag which lets you pass data from your controller to your page, but it clears after the page is rendered. There is also something called "Tempdata" which acts like Session state, but more temporary. However, it relies on Session State which is not an ideal way of persisting data. Session variables and tempdata variables are fine for user-level data (profile information for the person logged in), but having two different tabs open by the same user can cause these session/tempdata variables to overwrite each other when you're dealing with the actual model data.
If you're at a crossroads, I'd go with MVC. MS is pushing it and support for Web Forms will likely start going away

Related

implementing ASP strategy in ASP.NET

I've built several database driven web sites with ASP and I'm trying to migrate the basic functionality to an ASP.NET architecture.
I want to have each link in my navigation tree correspond to a different function that will step a user through various requests and provide sequential database driven responses and possible follow-up questions. I typically do this in ASP by using the query string to execute different parts of the code in an SSI file. Each link in my navigation tree basically calls a different SSI file.
In ASP.NET I think I have a pretty good handle on web form basics, data binding, site navigation tools and master pages, but I'm having trouble with the overall design picture.
Do I want to have each link redirecting the user to different pages? My understanding is that ASP.NET is much better at maintaining state information and so I shouldn't have to rely on the query string to keep passing values to an SSI file to do sequential parts of each task.
Should I be using BLL and DAL to do this and/or stored procedures and managed code? Or could I do this sort of thing more simply with ASP.NET web pages, as opposed to web forms?
Feedback that would include a reference article and/or web example would be greatly appreciated. Thanks!
You don't necessarily have to abandon your whole way of thinking and take up ASP.NET Web Forms.
I've been making sites with ASP.NET Web Forms since it came out in 2001. But I think ASP.NET MVC would be an easier transition for you. I mean, some things are more difficult in MVC than in Web Forms. But on the whole, MVC will promote more web friendly practices and it's what I prefer now.
For example, the whole idea of postbacks and viewstate in Web Forms certainly makes a lot of things easier. But they also have a problem of hurting SEO and breaking the back button. MVC doesn't rely on any of this and it's easier to refine the user experience with the way form posts, redirects, and URLs are handled.
I wrote an article awhile back comparing MVC vs Web Forms...
http://swortham.blogspot.com/2009/10/when-to-use-aspnet-web-forms-and-when.html
Based on what I'm seeing, it looks like you've got wizard-style navigation across multiple ASP pages, and you want to have wizard-style navigation in an ASP.NET (WebForms not MVC) site.
If I'm misunderstanding this, I'll gladly delete this answer.
I'd recommend the Wizard control, (Video demos available all over the place) which will provide such an interface in one page, reducing a lot of the complexity. there's no need to keep track of variables across pages - it's all in one page, and therefore always accessible.
Wizard pages do tend to have a LOT of code and markup, but the trade-off is that all of the wizard functionality is in one pace, not scattered across files, and it's inherently obvious what's happening at each step. With the multiple-file approach, a maintenance developer needs to trace which page posts to which page and spend more time understanding the design.
The article on MVC vs Web Forms was quite interesting, although after looking at a few training videos I got the impression that the coding is quite a bit different from ASP. (Most of the examples I also see involve C#, although I have seen a few with VB, which is preferred since I'm already learning a lot of new things in a short time.) Also, I wonder if MVC will let me use the validation tools, which will be quite necessary in a different aspect of this project that involves several different and quite long forms. Given that I've invested a fair amount of time in learning about ASP.NET, I'm wondering if I should just go the extra mile (or two) and learn how to create business objects (BLL) and a data layer (DAL).

ASP.NET MVP vs ASP.NET MVC

My company is trying to make an informed decision about how to pursue future development.
We seem to have narrowed down our future internal and external Applications to being web applications. But we are still a bit confused from that point.
There is a large amount of support for Sharepoint here. As I understand it, Sharepoint is basically ASP.NET using MVP.
Others want to use normal ASP.NET using the newer MVC style.
I am also told that these don't easily play well together.
It is looking like Sharepoint (and ASP.NET MVP) is going to be the winner. Before we go that direction, I wanted to ask:
If we choose to base the next 5-10 years of our development efforts off of Sharepoint (ie ASP.NET and MVP) what are we giving up? And is it a big deal or just some "nice to haves" that we are loosing.
(It would have to be a fairly big deal to get management to change direction now.)
Whatever happens, WebForms will turn into a big ugly mess at some point. If you have to use webforms, don't use the postback and page lifycycle model - have aspx pages with presenters for get requests, and have a handler or empty aspx per post. It'll feel a lot more like MVC that way
I would say that what you choose depends heavily upon who your developers are, and what kind of apps you intend to build.
If you build largely crud-like apps that make a lot of use of third party (or your own) custom controls, then staying with Webforms is probably a good idea.
If you build largely "web" style apps with lots of client-side functionality, then MVC is a much better choice.
If you have largely newbie developers, Webforms may be better. If you have more experienced developers, even if they're new to asp.net then MVC may be a better choice.
If you are building very data-centric applications with complex interconnections, then MVC may be a better choice.
There are lots of reasons why you might choose one or the other, and it's always "it depends on...".
Also, MVC and Webforms are not completely incompatible. You can't use them in the same page, but you can use both in the same site. Also, like the comment above says, Sharepoint is not Webforms or MVP per se.. it's kind of it's own thing that is based on webforms. It's very "Webpart" oriented, which is just a way of saying you build lots of custom controls.
I have been a strong proponent of Separation of Concern (SOC) being built into software whether you use MVVM, MVC or MVP all three patterns are quite nice. With this being completely specific to ASP.NET, I would state you should use MVC3.
I have been a .NET developer for years now and have written my MVP pattern that is built on top of StructureMap (lots on my blog about it) and for a while I never saw the benefit of dealing with the changes associated from leaving webforms to goto MVC. However after dealing with ASP.NET for so long I've just had it with ASP.NET webforms errors that are completely out of my control.
The main errors from webforms occur with the ViewState timing out resulting in the generic cryptographic exception and the 2nd is where the ViewState is just truncated by the client or post somehow resulting in legitimate cryptographic errors. With MVC these errors just aren't applicable anymore. With .NET4 I attempted to create a webforms application without ViewState with the new features they added in .NET4 and that completely didn't work which cemented by decision that webforms time is past.
Out of MVC, MVC2 and MVC3 the feature set that comes with the MVC3 and the Razor view-engine is the most robust. You get all of the enhancements that came with MVC2 along with the much cleaner Views that the Razor view engine lets you create, on top of that you get global action filters and the baked jQuery client side templating (I'm 90% sure).
I would also approach MVC very similarly to MVVM where I would have 3 distinct sets of entities, my view models, my domain entities and my physical database models. (The last set may, or may not be the domain entities, I've started to realize trying to make your pure domain entities work with your database layer can be suboptimal at advanced stages)
If you are performing page post-backs to handle events, I would suggest MVP as the Presenter would contain the event handlers for all versions of the view (Different user interfaces such as web pages, iPhone, Android, Windows forms), with a uniform behavior. In other words, you would not need to write control events in a code-behind for every view. At least, they'd do nothing more than call the Presenter's event handler method or raise an event the Presenter handles.
If you are creating web applications and heavily using Ajax for page updates, with one or more web views and a cross-browser JavaScript library, such as jQuery, I would recommend MVC.
So it comes down to how you want to handle page events. MVP & MVC both have separation of concerns. MVP is more server based and easier to add multiple UI's and MVC is more client based, for event handling and more web centric.
From my experience, a strongly enforced MVP pattern has been much better for data centric complex LOB applications.
MVP offers greater seperation as your presenters have no knowledge of web centric concepts.
Code coverage is also increased as you have no conditional code in the views.
We have several apps that where the presenter is used between both web and windows apps.
You presenter referes to a complete abstraction of the view, asp.net MVC relies on abstractions of view dependants (HttpContextBase etc.)
That all said you need to design this into web forms, its not out of the box, but if you do it right first time and have developers that understand it and stick to it you end up with a very clean solution.
there are some solid frameworks out there to support MVP in webforms:
http://www.codeguru.com/csharp/.net/net_general/patterns/article.php/c15173
webformsmvp dot com as well.

Has ASP.NET MVC made Web Forms a Legacy Platform?

Last week at Mix '09, the final version of ASP.NET MVC 1.0 was released.
Some of the stated benefits of this framework are:
Clear separation of concerns
Testability - support for Test-Driven Development
Fine-grained control over HTML and JavaScript
Intuitive URLs
Now, Microsoft are being careful to tout this as being "an alternative, not a replacement, for ASP.NET Web Forms", but given the advantages mentioned above, I'm wondering:
How long will it be until "classic" ASP.NET Web Forms is considered to be a "legacy" framework?
If you were kicking off the development of a new .NET web project today, why would you choose to use Web Forms instead of the ASP.NET MVC offering?
Good questions. I think ultimately, the answer is going to be the development team's expertise and the project needs that will decide that. ASP.NET web forms is so heavily used that it likely isn't going away anytime soon. Plus, there are so many custom controls and third-party support such as components and books. The main benefit of web forms is how easy it is to get a dynamic website up and going. It really is a RAD way of developing websites.
However, once that team has more experience with creating larger websites with much higher demands in terms of scalability, reliability, and test-ability, then they will look towards other solutions for that. In this case, they will realize that web forms are harder for unit-testing. They may also see that viewstates reduce performance and look for possible solutions.
Although MVC has the stated benefits, it is unlikely that anyone will convert their sites to use this new framework right away or ever. Plus, it requires the team to learn the new technology, and work out the new bugs. The team will have to learn new ways to do the exact same thing. For example, how easy is it to support uploading a file using MVC?
As I saw recently, there isn't a reason you can't create a site using MVC and web forms together. So you may see more hybrids in the near future. But I doubt that web forms will ever go away.
I kind of think about web forms like the way VB1 changed the way Windows applications are created on the desktop. To this day, the RAD way of creating application still exists and will never go away.
Keep in mind that MVC STILL uses WebForms for it's default View Engine. Sure, you can replace it with another one, but WebForms is still a core part of it.
Also, not everyone prefers to tightly control the HTML or the Routing. That's not my attitude, but some people just want their job done with the smallest effort.
And aren't .asmx Files technically part of the "old" Model as well? I can say for sure that a lot of people would not like to see them go away.
Still, I personally see ASP.net MVC becoming the main Web Engine for ASP.net in the future, although not in .net 4.0 yet.
You're asking when a newly-released web platform, ASP.NET MVC, will replace Web Forms, which has been around for seven years.
If we'd been crying out for ASP.NET MVC for the past seven years, then it wouldn't have taken seven years before ASP.NET MVC was released. The fact is, not everyone sees a need for this. Many of us have been creating complex, highly-scalable web applications for most of those seven years.
We even knew how to make them testable, and to separate presentation from business logic and data access. ASP.NET MVC may enforce this separation, but I've done it by using coding standards and code reviews, and by saying, "there's no unit test for that", and "get that business logic out of the UI".
Also, if I really needed more control of the HTML, I would write my own control to generate the HTML.
I do not believe WebForms will ever retire.
I've been using WebForms at work in business applications and MVC at home for some private things. Though I really like MVC I do not see how this could be possible to implement really complex UI logic with HTML/CSS/JavaScript. It will quickly become unmanageable and will be quite unsecure since JavaScript can be switched off to prevent disabling some controls or hiding some information. On the contrary, turning off JavaScript with WebForms will virtually turn the page dead for any action, either authorized or not.
Both platforms will continue to evolve. For general web sites and HTML/CSS lovers MVC is a way to go, with complex applications you would want object-oriented architecture and artificial event handling even though it abstracts you from the stateless nature of HTTP.
So, pick up what is best for you.
P.S. Dropping WebForms altogether will jeopardize the future of numerous projects and companies throughout the world. Microsoft folks would not want to become an object of hatred and the trigger that started the third world war.
WebForms will still have a place for those that want a pseudo-stateless web application that they can easily put together by dragging and dropping. For those that don't have to or want to understand how HTTP works. It's the ultimate in RAD for web applications.
ASP.NET MVC on the other hands allows much more finer control at the cost of more responsibility. You get complete control over your HTML however that means you have to sanitize/encode your output yourself. Your application for the most part has to be completely stateless and for some ASP.NET WebForms/Windows WinForms developers that it's a bit hard to wrap their mind around.
I don't think either will ever dominate the other though one may be favored.

Can Standard .NET CMS systems be made to work with ASP.NET MVC

Has anyone successfully used a CMS developed for standard ASP.NET with ASP.NET MVC?
I currently use Immediacy CMS and it seems to be quite tightly coupled with standard ASP.NET, but I'd really like to start using ASP.NET MVC.
Are there any CMS systems out there directed at MVC?
How could I persuade my employer to move to ASP.NET MVC?
I suggest take a look to Kooboo (kooboo.com), a simple to use but powerful for developers. Well documented API and based upon ASP.NET MVC (of course ;-)
N2 CMS has an example site in ASP.NET MVC that I've been playing around with that works quite nicely - note that the code is now hosted on Google Code.
The problem you've got is that many CMS' already do a lot of "routing" in that the pages you are requesting/editing don't actually exist on disk, but are all in a data store of some kind, and there's an HttpHandler or ISAPI Filter sitting in front of ASP.NET to intercept the requests and work out what should be happening.
I have not personally seen any of the big name CMS systems out there upgraded yet to take advantage of many of the new things the .NET framework offers, let alone start working on the MVC framework.
As with all things, a cost-benefit analysis is the best way to convince your boss to do anything. If you can point how how moving towards the MVC framework is going to make some immediate positives (as well as many long term positives) that can outweigh the costs (in time, energy, and money) in the switchover, then you have succeeded.
ASP.NET and ASP.NET MVC are very different beasts in terms of how you develop applications on top of them. Technically, an ASP.NET MVC application is an ASP.NET application with some generic handler that invokes the core MVC framework.
The ASP.NET MVC framework is also relatively new (1.0 just released last MIX) and so it'll take a while before becoming mainstream.
How you can persuade your boss? Talk to him about the positive sides of ASP.NET MVC, and how it will improve his future business. There's plenty of material available to demonstrate that.
I do a lot of work using Immediacy (I used to work there) and I had thought about doing the same thing a couple of months ago. I think that the main issues would result from things like the plug-in handler, the idoc handler and (if your still using it) the ilink hander.
When you enable things like friendly URLS I think this would cause issues if you had similar named methods in your controller actions.
You may be able use some MVC in your project, I could see it working as an admin add-in but I couldn't see it being used to usefully in the main webroot.
I would think a CMS would have to be built using MVC in mind to get the most benefits from using the pattern, instead of trying to make it work in parallel with a pre-existing system API (limited as it is) and making more work for yourself.

Do you plan move from ASP.Net Web Forms to ASP.Net MVC?

If yes, when? and how much time do you think that the process will take to migrate your current projects (if it's the case)?
ASP.NET MVC is not meant to replace WebForms. They are different technologies and are designed for different purposes.
Making a blanket statement of saying that I'll only use one and not the other is a very narrow minded approach, as you're missing the pros and cons of each technology.
Microsoft is commited to both technologies going forward and there are quite a few sweet new features coming in WebForms 4.0.
I'll be using WebForms and ASP.NET MVC, but looking at the needs of the current project so that I make the right decision for the current implementation
I've been using it for a few months now. I absolutely love MVC. Converting existing projects may not be realistic, depending on available time. As I see it, Web Forms simulates windows forms development for the old VB crowd. While MVC doesn’t pretend it’s something it’s not and follows the Http process more closely.
A few plusses I see in MVC
1) It’s testable with unit tests
2) Direct control over Html. We make websites, how do we accept not being able to control all our html?
3) No viewstate baggage
4) No control tree to waste time rendering
5) Automatic binding of a modal from a form post
6) It can be rather sexy
And a few disadvantages
1) No more web controls (and many rich 3rd party controls are lost)
2) Slower to develop in
3) Large learning curve
4) Still in Beta (CTP soon though)
Yes for my new projects. But not for current production software.
Yes, in as orderly a fashion as possible.
MVC opens .NET up to the world of Best Practices for Agile development. It specifically addresses concerns about Separation of Concerns, and coupling/cohesion. It also lets us write more-portable software without creating a dependency on any vendor-specific references or components.
It unquestionably is a successor to WebForms, along with WPF, regardless of whatever PR you might read.
The Wikipedia entry is pretty clear, even before being updated for Microsoft's MVC.
Assuming you prefer ASP.NET MVC to Web Forms, it's worth it for a system that's in active development/maintenance.
They can coexist side-by-side, so it's possible to migrate parts of the application (new ones, or selected old ones) and see how it works out. If it's a success, keep going.
An "all or nothing" migration could be disastrous, though - investing a lot without quick feedback is a huge risk.
WebForms are for rich UIs
These can be done just the same with MVC or Webforms. A year from now rich MVC based toolkits will arrive (technically they're already here if you like YUI, ExtJS, etc.) and make this argument null and void.
migrate your current projects
Migrating an existing WebForms project to MVC doesn't make a lot of sense. What are you going to gain? Using MVC for a new project however can make a lot of sense depending on your requirements.
I was never really fond of WebForms to begin with so getting to work with MVC was like a breath of fresh air to me. I've always much preferred the separation of concerns as I could work on the chunks that I was really good at developing, the logic and the data access, and leave the presentation work to the members of the team who had that natural ability. I think the MVC library makes it easier for teams to work together on individual pages as one person can work on the controller and the other person can work on the view.
All that being said, when I'm working on projects where I don't need to focus as much on the coding and it is more display oriented, I still go back to the WebForms because they are so much easier to implement and get up and running. Both have their places and I don't think one will ever supersede the other.
I've been using ASP.NET MVC for several months now and I prefer it to Web Forms. However, I don't see myself migrating my existing projects to MVC. For me, it would be rather pointless. However, all of my new ASP.NET projects will (or should be) developed using MVC, as it is a much better (and more flexible) framework.
Personnaly I restricted ASP.NET MVC for lightweight Front Office Web Sites.
But still using ASP.NET WebForms for Righ BackOffice Applications to take advantage of rich custom controls and some of other nice features of Web Forms.
Another plus for mvc is that javascript like jquery is much easier to implement, so if you plan on using a lot of js, mvc might be the way to go.
No, there's no reason to. It's an alternative style, one I am not fond of. But that's just my opinion; a lot of people like it and I hope it works well for them.
As already said, they're not mutually exclusive, and I play to make good use of both.
IMO MVC is better for web sites, while WebForms are better for web applications.
For example, this site is a perfect showcase for where ASP.NET MVC is a good choice because of the nature of the site and what needs to be accomplished; other good examples would be a web store, or a project management site (like Basecamp), or a social network.
If you were developing a corporate CRM/ERP system, however, I'd stick with WebForms to get rich controls and a more "desktop-like" programming model, since a CRM application is traditionally the domain of a desktop application.
ASP.NET MVC fits my desired style of development better, but I'm wary of trusting myself to it whilst it's not been RTM. It also is different enough that our legacy code will not work with it. If we had been practising Domain-Driven Development things might have been easier, but ...

Resources