ASP.NET MVC – Model != BLL or DAL

Last week I introduced the ASP.NET MVC framework by talking a bit about what the model, view and controller are.

In the comments, John Meyer said,

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.

While historically, MVC has been described in the way I stated–while the ASP.NET MVC guys have also portrayed the Model as BLL or below–I have to agree with John.  Here’s why:

At least as far as ASP.NET is concerned, the model is inherited from a specific class.  This means that any implementation code you place in the class will be forever tied to the class it inherits from.

So if in some point in the future you decide that a WebForms implementation would work out better for you, or you wanted to put a Windows Forms implementation on top of it, you’d have to do quite a bit of refactoring of your code just so you could.

If instead you treat the Model as a “View Model” as John suggests, and have the View Model call the Business Logic Layer, you end up with two major benefits.

First, your Business Logic Layer is completely decoupled from the View implementation.  You are no longer forever tied to MVC as an architecture or ASP.NET MVC as the primary architecture.  You can use whatever view implementation you want.

Second, you are not forced to put View specific data code in your Business Logic Layer.  Doing so would cloud the actual implementation of your BLL and actually further couple your view layer to your BLL, something that third tier is specifically designed to avoid.

Based on the feedback from John and my own thinking on the subject, I recommend a three-tiered approach that places the MVC as the view entity calling the BLL from the Model of the MVC set, which would in turn call the Data Access layer.


Other post in ASP.NET MVC

Related Post

  • ASP.NET Model View ControllerASP.NET Model View Controller 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 ho...
  • Internationalization – The DatabaseInternationalization – The Database Over the last several weeks we’ve been examining the various aspects of internationalization using ASP.NET. But it doesn’t help to have your resources and images set up for internationalization i...
  • ASP.NET MVC – Controller to ViewASP.NET MVC – Controller to View A couple of weeks ago we looked at ASP.NET MVC routing in the MVC framework.  The routing controls which method in which controller gets called. The obvious next question is, how do we get fr...
  • ASP.NET MVC – Is The Grass Really Greener?ASP.NET MVC – Is The Grass Really Greener? There are three ways now to write a web site in ASP.NET: Use Classic ASP model with everything in the ASPX file and only use HTML controls without the runat="server" attribute Use the Web Fo...
  • ASP.NET MVC – RoutingASP.NET MVC – Routing One of the core features of ASP.NET MVC that makes everything "just work" is the concept of routing.  By specifying ahead of time what a route looks like, we can create links that look like r...
  • SBC

    I would think the ‘M’ in the MVC is ~= to the BLL/DAL.. my reference is to John Meyer’s comment in the prior article..
    the implementation of the MVC in ASP.Net is what introduces the weakness (via the inheritance).. MVC is an abstraction but somehow the implementation (varying by platform) muddies it.. the original implementation done in Small Talk almost 2.5 decades ago had perfected it..
    If I recall right, the SmallTalk MVC had more coupling between the ‘V’ & ‘C’ (compared to John’s suggestion of the ‘V’-'M’ coupling), this maximizes the decoupling of the ‘M’ which is what the design goal should be (or would be)..

  • Dave

    To be accurate, ASP.NET MVC isn’t MVC in the purest sense of the model. I think Microsoft originally referred to this as a Front Controller.

    As my original articles on implementing “MVC” in ASP.NET state, you can’t truely implement MVC on the web due to the fact that the View is ultimately detached from the Controller. At least the implementation that we have now in ASP.NET makes an attempt to attach these again.

    It would probably be helpful if we just stopped calling this MVC but then it wouldn’t have the marketing backbone it would need to take off. When web guys think of MVC, what ASP.NET MVC gives us is generally what they are thinking of because this is what the Java/JSP community has been calling MVC via the Struts framework.

    So, while the M in MVC really is the data layer, either via BLL or DAL, in the truest sense, and even if you proxy it with an ASP.NET Model class that ultimately calls down to a more generic BLL or DAL what is helpful about John’s suggestion is that it takes make this weak model stronger simply by introducing a layer similar to how Properties primarily add a wrapper around member variables and the BLL adds a wrapper around the Data Layer. In both of those cases, 80% of the time the wrapper is acting as a passthrough, but we’ve set ourselves up for ease of maintenance moving forward. If we need to do extra work in the BLL or need to scrub data before we assign it to the member variable, we can without having to refactor a lot of code in the process.

    Making the ASP.NET Model work as a passthrough gives us the same benefit.

    Maybe we should refer to Web based MVC as WMVC to distiguish it from the original MVC introduced by SmallTalk.

  • Pingback: Dew Drop - February 11, 2009 | Alvin Ashcraft's Morning Dew

  • Pingback: Arjan`s World » LINKBLOG for February 11, 2009

  • Bart Czernicki

    Very nice post…I agree completely.

    One danger that I see is that a lot of videos/examples of MVC are showing the Model as a “direct access to the database” with LINQ/EF/NHibernate and are not really providing proper direction how this would be done in an enterprise level application.

    I agree with the other posts…I see the Model as a passthrough the some kind of BLL (service/caching/DAL/database logical layer inside it).

    To take this topic further is how do we treat Views in an MVC application? How do more complex views get created? For example a Silverlight view? Do I really want to be passing in View/ViewData to my Silverlight app or do I maybe want to pass it a URI instead and let it handle its architecture individually (MVVM) maybe with a complimentary REST service access?