C# ASP.NET, WebForms to MVC : Does it make sense to change in our case?

Question

We have a WebForms based web application with these properties:

Large Business Object Framework (Close knit DAL / Business Objects / Serverside Validation, similar to CSLA) Precompiled and placed in the Bin folder. Uses a lot of UserControls.

Looking at overviews of MVC it seems there is a distinctive split on how the code is split up, there is no Session State (which seems odd, but possibly ok if the website is primarily serving content?) and it appears constructing pages looks similar to classic asp (use of <% %> tags)

Do I have the wrong interpretation of MVC? Is MVC just a specific architecture, or is the way things will be going and WebForms will eventually be dropped? How does one split the M-V-C when an existing Business object Framework exists? Why is there no session state? Do UserControls work in MVC?

I realise this could be subjective, so mostly looking for your comments on the subject to make my up my own mind.

Answer 1

MVC is 90%+ the same as WebForms, but of course when everyone's having debates they tend to leave that tid-bit out.

You can have as many layers underneath as you want providing yor data, and yes you can do the UserControl style. It's more of a mindset change than a technology change. MVC has it's advantages, it embraces the fact that HTTP is stateleess. Webforms abstracts that fact to a degree, making some things easier as well (viewstate for example). Session state, compilation...it's all there, it's in the same framework beneath both.

In short: use what you want, research it well (example projects are everywhere). If you're deep into a project, factor in time to change over, it's learning curve as well as the actual code time. This decision is up to you and your team, if it's too different, then it may not very beneficial because there is some adjusting. If you're more comfortable with new technology, MVC can be much cleaner...both still have their uses.

I wouldn't start another project in WebForms, but that's me, and what I'm comfortable with...you really have to figure out which feels more natural to you, and if applicable, your team.

Also, tvanfosson made an excellent point: the more validation or really whatever custom logic that was in the web project before, the more time it takes to move over. If you have an excellent separation of layers already, you're in a much better position to do so, if not, that's another major time consideration.

Answer 2

It sounds like you have a lot of coupling between your domain model and your presentation. It would take a significant amount of rearchitecting if that's the case. MVC does support Session state, but it doesn't use ViewState -- it sounds like you have a bit of confusion there. It doesn't support normal UserControls or anything that is dependent on ViewState. You can create "controls" for MVC (referred to as "partial" views) so that functionality is there, but in a different form. In MVC your views are very decoupled from your business model, typically you'll have a set of view-specific models that mediate between the two and the views are strongly-typed to the view model, not the business model.

While I would recommend MVC as a better architecture for web-based applications, in your case I'm not sure it makes sense to switch (at least now). I'd recommend either sticking with WebForms (which won't be going away according to Scott Hanselman) or slowly migrating parts, starting with new features (or apps), over to MVC.

Answer 3

MVC is a shiny new bottle for the same old wine which is the web & the way it works.

On the other hand, you can finally move away from the asp.net viewstate & page lifecycle, postbacks, crazy URL's etc.

If you need to move from webforms to MVC, look at the dependancy on third party controls which you might have used in your application UI. Not all the vendors have MVC equivalents as yet. Sessions & ViewState are the other most important aspects to look at at the UI end. If you have a public facing web application, think of the URL's being bookmarked. All these might be additional factors to look at when moving to MVC.

Typically, I would recommend to first factor your code into Model-Controller layer & once that is complete, then change the UI into View & use the URL routing mechanisms of MVC. Alternatively you could use the any decent URL rewriting module & publish REST-style URL first & rewrite your old URL to the new URL & then slowly convert sections of your application to MVC.