dotnetguru asks how MVC relates to traditional 3-tier architecture.

  1. DotNetGuru on November 8th, 2007

    Hi Steve,

    I was on ScottGu’s website where i found the link to your site. I am actually a newbie to architecture and trying to get hold of MVC. I would repeat the same questions i asked over there. Kindly could you answer the following questions:

    1. In an asp.net application, which part (forms, classes, controls etc) represent M-V-C respectively.

    2. How does MVC fit in a typical 3-tier architecture (are they two different?) and what if

    there are more tiers added? How does a typical UI, BLL & DAL relate to MVC. I have also heard that MVC can be applied to an individual layer. Could you elaborate that a bit.

    Thanks…

  2. Steve on November 8th, 2007

    That’s a very good question and would probably warrant a full post to answer it completely. I’ll summarise my opinion, but this is just my opinion…

    MVC is a design pattern for user interfaces. It dates back to the late 1970s, and has recently become very fashionable. Different programming frameworks may implement MVC to differing degrees - some very strictly, others only by loose conventions.

    ASP.NET has never implemented MVC in any formal way. In the worst case, meaning if you follow the demos Microsoft show about how easy it is to build ASP.NET pages quickly, you can drag a gridview on to a web form, connect it to a DB with an appropriate SQL query, and enable the automatic editing support in the grid. In this way you have absolutely *no* separation of concerns - the model, view and controller can’t be distinguished and you just have a big bundle of stuff. User interface, logic and data itself are all mashed together. For maintainability, this is very bad news.

    You can, however, choose to follow MVC principles to some degree while using ASP.NET. This answers your question [1] - the ‘model’ might be a set of .NET classes that represent the ‘real world’ entities (customers, orders etc.) that are ultimately stored in the DB. You can think of your ‘code behind’ (C#/VB.NET) classes as ‘controllers’, as they hold the logic to handle each request, and as they do so, they manipulate and populate the UI controls in the ‘code in front’ (ASPX), which is a sort of ‘view’.

    The problem is that ASP.NET encourages us to mix business and view logic together into the code-behind classes, and perhaps to actually generate portions of the view there too with string concatenations etc. We’re not really supplying clean model entities to the view, and we’re embedding business rules (validation etc) as “Validation” controls in the view rather than in the controller. Ultimately nobody can keep it tidy and our apps inevitably become unreadable, untestable mush. The upcoming ASP.NET MVC framework is an exciting initiative from Microsoft to try to address these problems (this only addresses server-side MVC, unlike jMVC.NET which is targetted at client-side MVC).

    [2] In typical 3-tier architecture terms, it can look like this:

    Bottom tier = Data layer = Model

    Middle tier = Business rules = Service classes (this is sort of outside MVC)

    Top tier = user interface = Controllers (to handle requests by calling into the service layer) and Views (used by controllers to render UIs in response to requests)

    There are no doubt many other ways to put this together, this is just an example. Note that I’m mostly talking about a completely MVC-oriented server-side architecture, which is very different to the problem that jMVC.NET solves. jMVC.NET is designed to be dropped into non-MVC architectures, and provides a simple and powerful MVC-like way to build dynamic client-side UIs.

    Does this make sense? If I can clarify further please just ask.

  3. DotNetGuru on November 11th, 2007

    Steve,

    Thanks for replying. Yes what you said makes sence and I better understand it. Actaully every person looks at MVC with their perspective giving rise to many question.

    http://forums.asp.net/p/1020216/1381246.aspx, looking at the above discussion, 1) Do you think MVC is an Application Architecture Pattern? 2) “Every physical layer of your system should implement its own MVC”, how do you look at this comment? 3) Is MVC different for 3-tier and 3-layer where tier refers to physically seperate entities?

    Thanks for your time and help…

  4. Steve on November 11th, 2007

    Wow, that forum makes it all seem so confusing! Like you point out, there is no ’standard’ or ‘correct’ architecture, and nobody owns the term MVC.

    That said, for web apps we’re starting to converge on common approaches — Ruby on Rails, Castle Monorail and the upcoming ASP.NET MVC framework all look strikingly similar to each other.

    [1] Erm, not sure about how well defined these terms are, but you can build your entire application architecture around MVC if you want to. Could you clarify what you’re getting at?

    [2] I feel most comfortable using MVC as a pattern for my UIs only - that’s what it’s good at. I can’t imagine why you’d want, for example, some sort of model-view-controller separation for your business rules implementation or any other stateless components.

    You should only build a sophisticated architecture if your application warrants it, or you’ll lose more time than you’ll save long-term.

    [3] I understand that “tiers” are meant to mean physical entities, like servers or OS processes, and “layers” are supposed to mean logical boundaries in code. These are not standard terms as far as I can tell.

    To answer your question, no I don’t think this makes any difference. As programmers we must consider how our applications will scale up if needed, so physical deployment considerations do matter. However, it doesn’t make much sense to put the M/V/C layers on physically different servers. If you would like to discuss this further, do you have a specific example or situation in mind?

    Hope that’s helpful

    Steve