ASP.NET Model View Controller

ppl-act-012 Last week the ASP.NET Model View Controller framework was released as Release Candidate 1.  That’s my cue to take a look at what we finally have available to us and to start a series explaining how it all works.

What we want to take a look at today is exactly what MVC is and why someone might want to use it instead of the Web Forms we’ve been working with ever since ASP.NET came out.

<

I was first introduced to MVC in a web environment through the Struts framework for JSP.  (Yes, I did Java and JSP for a while.)

When ASP.NET first came out, many people who were familiar with Struts were asking, “How can we do MVC in ASP.NET?”  And at that time, I wrote the first article addressing the problem and offering a solution.  You can still read that article e. It’s still a pretty good introduction to what MVC is and if all you know is ASP or ASP.NET development, that article may help you better understand how MVC compares to what you already know.

The new offering from Microsoft actually implements the MVC framework very close to how the Struts framework was implemented, with distinct and separate Model, View, and Controller.

There have been different attempts along the way at describing what should be in each model, view and controller.  Here’s my current pass:
<

  • Model – This is what we generally consider the Business Logic Layer.  This is where you want the bulk of your code.<
  • View – This is the presentation layer.
  • Controller – This is the decision maker layer.   This is the part most people are going to have the most trouble with.

If you are familiar with the three-tiered architecture, you probably already understand why you need a Model and a View, but what the heck is this Controller thing, anyhow?

Have you ever had a Web Form that had two or three different presentations depending on some condition?  Sure you have.  We all have.  It made sense in a Web Form.

In MVC, instead of having multiple presentations in one view, you have a separate view for each of those conditions.  It’s the controller that decides which view should be displayed.

So instead of having one form that does edit, add and view, you could have three different forms that represented those three different views.

Is MVC easier?  I guess it depends on what you mean by easier.  Can you get a web application up and running quickly?  No, probably not as quickly as with Web Forms.  Do you have more control than Web Forms?  Yes.  Is it easier to maintain?  Maybe.

But until you understand how it works and what you can and cannot do with it, you can’t really make an educated decision about using it or not.  “When all you have is a hammer, everything looks like a nail.”

So stick around and we will explore just what we can and cannot do with ASP.NET MVC.

 

Other post in ASP.NET MVC

Related Post

5 Responses to “ASP.NET Model View Controller”

  • [...] ASP.NET Model View Controller (Dave M. Bush) [...]

  • John Meyer:

    I respectfully disagree with your claim that the model is you BLL. MVC is a UI layer pattern, and as such all models, views, and controllers are strictly in the UI level.

    You give an accurate description of what is often referred to as a domain model, but an MVC model is a not a domain model. For lack of a better term I’ve been using “view model”. It’s a bucket for controllers to pass data to views, this way the views can be as dumb as possible. Another pattern I’ve seen is for the controller to initialize a view model with a domain model, the view model having properties that expose to the view the pieces of data it needs and the logic to get those pieces of data from the domain model.

    Also keep in mind that one of the weaknesses is ASP.NET web forms is testability, and the separation of concerns in MVC makes testability a strength.

    Anyway, I’m glad to hear differing opinions as I think it’s good for learning to see the different ways that applications can be architected, even on top of the same framework. Thanks!

  • Dave:

    Interesting perspective, and while my presentation is largely based on 1) How MVC has historically been explained and 2) How the ASP.NET MVC gues are presenting MVC, I think I largely agree with you. So much so that I’ll probably write a full post on the topic next week.

    I tried to stay away from the advantages/disadvantages in this post and instead explain how MVC is similar to and different from WebForms so that those who want to grasp this new architecture can. That’s largely why I presented the model as BLL. That’s what most ASP.NET programmers are going to understand if they understand anything about architecture.

  • We have a team with the Ohio DYS agency that is working with a consultant to put together a MVC application for their main interface with their facilities. Interesting to read about how the technology works and what are the advantages.

  • Vic:

    John Meyer – M-V-C’s “Model” at the UI layer? I respectfully disagree w/ you sir.

    Being around 30 years ago studying from it’s ealiest incarnation (“Model-View-Editor”) , “Model” (as with “MVP”) has always represented the thing that you’re trying to represent on the screen. Now granted, some who don’t unestand it’s origins/intentions incorrectly assume the “Model” exclusively means some data store, database table, etc., but “Model” really refers to just as I described – anything that is stateful in nature (disk or memory) of which you want to represent in a computer system. This means a “system” – a thing, idea, even a process. Now, I would also agree that “Model” doesn’t equate to the BLL, but I believe the truth burried in that, is that “Model” represents – what the BLL is abtracting (those things, sets of things or processes – i.e. “systems”), is definitely not the UI /presentation layer. The entire underlying strategic purpose of MVC is in fact the opposite – to keep the UI and model separate.

    Could you be confusing M-V-C with -V-VM (<Mode/DataModel-View-ViewModel)? With that pattern, they make a distinction between the “DataModel” traditionally the “Model” of “M-V-C”) and the “ViewModel” – a more “view-specific” functionality arsenal and DataModel subset specific to that view – that lives in the presentation layer. This is actually taking the place of the “C”, in that it serves to remove all logic in code-behind form (Web or Win) like the “C” traditionally did. But even in M-V-VM, although often physically bound to the “V” (via properties, like in WPF), the “VM” is still logically view-agnostic.

    1 thing that never sat well with me was the fact that in trad. MVC, the view was allowed to grab state frm the model; at least the more moden patterns (MVP/MVVM) shy away from that (at least on passive mode), completely abstraciting the 2 (“P” and “VM” mediate appropriately).

    Oh well hope this helps…