Home » ASP.NET MVC » ASP.NET MVC – Model != BLL or DAL

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 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 […]
  • WebForms vs MVC–The War Is OverWebForms vs MVC–The War Is Over loading... I just finished listening to a DotNetRocks podcast today with Paul Sheriff which largely talked about creating mobile web sites using ASP.NET WebForms. During the show they […]
  • Software Architecture without Test Driven Development is DANGEROUS!Software Architecture without Test Driven Development is DANGEROUS! I’ve had two incidents recently that have shown me how TDD impacts Software Architecture.  Both of these are with code I’m working on. What Software Architecture Might Do Software […]
  • Is Your Architecture Crippling Your Unit Testing?Is Your Architecture Crippling Your Unit Testing? Last week I wrote a post that talked about Unit Testing and the need to make sure you are only testing one particular unit of code at a time.  The post was well received.  But […]
  • ASP.NET, Angular.js & html5modeASP.NET, Angular.js & html5mode I’ve been looking at Angular.js recently.  I’ve already got enough of a project done in MongoDB (with Mongoose), Express, Angular and Node.js (MEAN) to be comfortable with how Angular […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer focusing on ASP.NET, C#, Node.js, JavaScript, HTML, CSS, BootStrap, and Angular.JS.Does your team need additional help in any of the above? Contact Dave today.

2 Pingbacks/Trackbacks

  • 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()

  • 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?