tiered webforms classified as MVC?

Question

Where I work, we have a project, written in .NET3.5 as a webforms project. It is tiered; presentation layer, logic layer, and data later.

We have these weekly 'tech sessions' at work. I gave a presentation about MVC.

My tech lead decided to cut in, and tell me that the project above (tiered, webforms) is the same as MVC. He went on to describe the following:

• Views are just ASPX pages
• Controllers are just page-behinds
• Models are just data objects

Long story short - we got into an unsettled debate over whether the project described above (tiered webforms) constitutes MVC or not.

Can someone provide and answer to this debate?

Thanks

Answer 1

no. mvc is used mostly for strong separation of concern. the controller and view are not tied together and have no knowledge of the other besides the passing of a model (or not). a single controller can be used to render many views, where as the aspx code behind is strongly tied to a single aspx page, as they are all part of the same partial class. the model is less different, other than to say in most mvc applications the models are not the actual domain data types, but rather some composite that can be used to render the view.

the other thing that is different with mvc is the rigid heirarchical folder structure and naming convention. this promotes best practices and, again, separation of concern.

microsoft created the asp.net mvc framework for a reason, and though you may be able to emulate some the feel of mvc in web forms using routing and such, it is not and won't ever be quite the same thing.

also, while this has been slanted toward asp.net mvc, there are obviously many other flaors out there. i'd suggest you check out FubuMVC as well.

Answer 2

As a pattern MVC is agnostic from any specific technology (WebForms, WinForms, ASP.NET MVC, etc).

So it is very possible to actually do MVC in WebForms.

CodeBehind files can be treated as controllers, but technically it is incorrect: both code behind file and aspx file are compiled into just ONE type (as they are partial classes), so there is no controller type and view type in this matter ;) But we may consider this difference as a minor one.

WebForms CAN be viewed as something implementing MVC pattern, admitting that it is a very ugly implementation that can be very easily messed up. But once it is messed up (as it usually happens), the whole idea of separation concerns between View and Controller at least is violated, so once this separation blurred or disappears we should say that it is not MVC anymore.

Resume: WebForms could be treated as an implementation of the MVC pattern, bot it is really hard to follow this pattern in this implementation so it very rarely remains MVC and stays within its concepts.

Answer 3

To be blunt, the tech lead is wrong.

There is a common misconception amongst people that have never used a true MVC framework before, that "MVC" is just a different flavour of webforms, when in fact, nothing could be further from the truth.

To understand why this is the case, you need to understand the difference between MVC, the architectural pattern, and ASP.NET MVC, the framework built by microsoft that implements the MVC pattern.

Often, people such as tech leads and architects that don't quite understand the topic, will use the term "MVC" to describe both the pattern and the framework without understanding the difference between the two and this often leads to confusion.

So, to be clear, the MVC pattern is nothing new, and it is in fact implemented by a lot of frameworks such as:

• ASP.NET MVC
• Ruby on Rails
• Interface Builder

Webforms is not one of the frameworks that implements an MVC pattern out of the box.

Now it is true that you could implement an MVC pattern in WebForms but Webforms is more suited to implementing an MVP style pattern and there are in fact framework around (such as this one) that will help you in this regard.

The biggest indicator that the tech lead has no idea what he's talking about however, is this:

My tech lead decided to cut in, and tell me that the project above (tiered, webforms) is the same as MVC

Introducing "tiers" into your application has nothing to do with MVC. In fact, within a tiered architecture, an MVC application would sit entirely within the presentation tier and have nothing to do with the other application tiers.

Using ASP.NET MVC for your front end means that your have a presentation tier that sits on top of your logic layers that is implemented using the ASP.NET MVC framework. It doesn't mean that you've suddenly removed the need for the other tiers simply because you're using MVC.

Conversely, Webforms is just the presentation layer within the tiered architecture. Just because you're using a tiered architecture in no way implies that you're using an MVC pattern.

To each of the other points:

Views are just ASPX pages This is not true. ASPX pages are very complex beasts and have one very major difference between MVC views:

They're designed to maintain state

They have this whole system of a page lifecycle and viewstate and controls that is designed to maintain state between postbacks.

ASP.NET MVC is designed to be stateless and as such, the views contain no such complexities.

Controllers are just page-behinds

This statement completely misses the point of controllers.

Codebehinds are explicitly aware of everything that is concerned with the process of rendering an ASPX page. It knows about the controls on the page, the state of a page, the lifecycle of the page and is very tightly coupled to the view.

A codebehind is also only ever going to return 1 thing. An aspx page.

Controllers are far more flexible and can return not only views, but they can be used to control the logic for rendering out different representations of your data. For example, you may want the same data to be rendered out as HTML for a standard http request, or rendered as JSON for an AJAX request.

This is possible because the controller logic and view logic are loosely coupled which is what makes this possible.

Models are just data objects

This is wrong. It's rare in any sort of MVC application with any sort of complexity that you'd bind your data objects directly to a view. Simply put, the way your data is modelled in the database will rarely represent the data that is required to display a view.

For example, say you have an employee record, which has a "TitleId". The data in the record would just be an int, but you'd need to display an actual text value to a user for it to make any sense.

So, in most MVC applications, your "Model" would actually be more accurately described as a "ViewModel" and is completely seperate from your data or domain models.

To summarise

Your tech lead is wrong, and not just wrong at a semantic level, but wrong in a "you-have-no-idea-what-you're-talking-about" level.

• Using a tiered architecture with webforms does not mean you have implemented an MVC pattern.
• ASPX pages are nothing like views
• Codebehinds are nothing like controllers
• Models have nothing to do with your data objects.

Hope that helps.