Is MVC ever considered/applied system-wide?

Question

I was having a discussion with a colleague and he bought up the topic of MVC and the use of ViewModels in ASP.NET MVC.

The discussion was that, in an n-layer architecture, the UI, Business Layer and Data Access Layer are individual assemblies/projects and ViewModels are the UI's representation of a database/business object. The discussion on whether ViewModel's are useful moved into a discussion about how MVC should be applied.

In my version (which is what I am used to/have seen elsewhere) takes into account separation of concerns and waterfall dependencies, where the UI project references the BLL, the BLL references the DAL and possibly all of them reference an "Entities" project. "MVC" is restricted to the UI. That is, the notion of "Models" (in my version, they are technically just ViewModels), "Views" and "Controllers" are individual files/objects in the UI layer. The BLL talks in terms of database entities and the UI will generally contain helpers that map a ViewModel to an entity.

My colleague's version took this to the system/layer level, where the "Model" is the DAL, the "View" is the entire UI and the "Controllers" are the BLL as a whole.

Given that in an MVC triad, the Model is unaware of Views or Controllers, the Views know about Models and the Controllers know about both.. does the system-level application of MVC not violate modular programming concepts/code reusability (disregarding the possible circular dependency issues)?

Are patterns such as MVC applied at a system level often? My understanding was that MVC and related patterns were more often applied purely to the UI and not spread out across an entire n-layer system.

By the way, we had a look at this question: What is MVC, really?

..but we also seem to disagree on whose argument the answers to this question supports! :)

I could be just stuck in my little tiny .NET-oriented world and cannot see the bigger picture, so I would like to hear some thoughts on this.

Answer 1

MVC has become such a buzz-word that it gets applied to everything and the kitchen sink. If you can distinguish a triad with different responsibilities and their communication lines are not all over the map, it will get labelled with the term MVC.

Originally, MVC was a pattern for user interfaces, where the View was responsible for updating (portions of) the screen, the Controller responsible for interpreting the input events (originally key presses and mouse movement/clicks) and the Model contained all the rest.

If you apply this model of MVC to the n-tier system you describe in the question, the UI layer would contain the View and Controller and the BLL and DAL layers together would be the Model.

But, as I said, the term MVC has been eroded in the past few years due to its popularity and other uses have sprung up.

Answer 2

From my experience, Controllers hide all the business logic behind them.

Basically, when a page is requested, the Controller will perform all the necessary business logic operations, create the models and pass them to the views.

BLL (and DAL behind it) is usually encapsulated in a separate project/module, and the Controller will work with it via an API.

The models, frankly saying, have nothing to do with the DAL or BLL. They needn't be the objects used for working with the database, and they needn't be a "copy" of the table schemes either. In fact, such approach has many drawbacks, because models are designated to be used by specific views, and the data needed for the views mostly isn't simply a set of rows from tables. Models can be placed in the same project with the Controllers.

This approach helps to view the whole project as having the MVC pattern. Along with that, it helps creating all the familiar layers (DAL, BLL) without breaking the pattern.

Answer 3

you're right - MVC is a pattern that can be conceptually applied as a kind of n-tier architecture. M = data tier, V = presentation tier, C = application tier. No problem there. The data tier doesn't know about who's going to consume the data that's exposed via a stored procedure "API", nor does the app tier know who's going to consume the webservices API that it exposes (for example).

Where I think you're getting confused is because you're thinking in "framework" mode, where you have a framework that is organised in a MVC way, and now everything looks like this in the frameworks realm. ASP.NET MVC is a framework that gives you a way of writing web apps in a particular fashion, however, it sticks to doing things in its own way and its not a full-on system architecture - WCF web services are not part of its remit, so it doesn't do them. You could think of it as a very simple system architecture, one for beginners before they architect larger systems that are more decoupled into the tiers. This is perhaps why you think of it (and therefore MVC as a whole) as something that effectively only applies to the presentation tier.

What this means in practice is... nothing :) You should continue the discussion down the pub for best results.

Answer 4

MVC is a great way of implementing a web interface because it makes things clean and maintainable and offers a useful separation of concerns. But it doesn't really describe an entire system any more than a windows interface system like WPF or Winforms describes the entire application that it provides the front end for.

However, like any design pattern it is also a paradigmatic way of looking at the world, so if you wanted to see things through the filter of MVC you might say that on a larger application the View is your MVC framework application, the Controller is your business process layer and the Model is your ORM layer or whatever other data source you use. Doubtless you could see MVC within MVC within MVC to a fractal degree if that was the way you chose to look at an application.

It is not the only way of looking at the world, and not necessarily a useful one but the more different ways you can see the same system the more rounded your understanding becomes, so it is by no means a bad idea to see how you can interpret a system through different paradigms, especially during the early design stages.

Answer 5

I actually had this discussion with a colleague this very morning, in the context of our own software.

A fair amount of the ASP.NET MVC software I've seen seems to be a little confused with regards to where the business logic goes. There isn't really a set "logic layer" in the framework. The most common approach seems to be to put the business logic in the controller. This suggests that the DA/BL/UI model maps directly: DA = Model, BL = Controller, UI = View.

The problem is that you often find yourself having to handle more complex presentation logic, creating viewmodels which hide away any details of the internal implementation that the user and UI don't need to know about, and/or wrap up various bits of information that the view will need. If your controllers start handling a lot of this as well, then your presentation and business logic layers have started to merge, which is generally a bad idea. There are ways to keep the logic in the views (if you're that way inclined then using Knockout makes your views able to do more of the work themselves, for example) but in many cases the presentation logic spills out. What I tend to do when that happens is to pull the logic out and leave the controllers to focus on dealing with viewmodels and user interactions.

With the View and Controller now under the banner of "UI", you're left with data access and business logic both needing homes, and only the M of MVC left free. At this point I tend to create a new layer; a set of classes that handle the business logic. I model these classes on the controllers, in that there's one for each "area" - often one per model, but not always. For example, a simple web store might have a ProductsController handling the product listings pages, and a corresponding ProductsManager handling the business logic around Product objects. Any controller can use the ProductsManager if it needs to, but most of the stuff that will need to will probably be in the ProductsController.

How you refer to this is a matter than can be debated (and has been, quite a bit). It boils down to whether you consider these logic-layer classes to be part of your model, and that mostly depends on what you mean by "model". If you think of the word "model" as meaning "a representation of an entity (or system)", then these logic-layer classes are more likely to be something else, and you've turned MVC into MLVC or something (which is fine). If you think of "model" as meaning "a representation of an entity or system and its behaviour", then yes, these logic-layer classes are part of your model, forming the "behaviour of the system" part while your entity classes do the rest. It can be argued that the latter is more correct, or at least closer to the definition of "model" that is commonly used by people like systems analysts.

Answer 6

Be careful not to apply design patterns in general liberally. Design patterns are intended to simplify or clarify design purpose and create better organization. Design patterns should not be considered a goto in place of proper, well-thought programming.