2

Fowler refers to the MVC, as a GUI architecture:

There have been many different ways to organize the code for a rich client system. Here I discuss a selection of those that I feel have been the most influential and introduce how they relate to the patterns.

If MVC is a GUI architecture, then say that the M in MVC are the business rules or domain is not wrong?

6

MVC was originally designed to solve the problems in architecting GUIs. It decouples the process of extracting data from the model in order to present it from the process of presenting it. Basically it is an application of the Single Responsibility Principle to GUIs.

This has a number of large advantages: it takes away the need to have logic code from the presentation layer and it makes the controllers testable, thereby increasing quality and reliability. Early web GUIs, like classic ASP, had logic code embedded in HTML pages which was hard to maintain and just made you feel dirty.

The Model is basically a black box representing the application and its data, and will typically be an n-tiered application. The View is to display the data from the application and typically pass commands and data back to update the application. The Controller mediates between the Model and the View, presenting data to the View and commands to the Model.

So the Model is, as you say, the business rules or domain (or it could just be a database), but the entire architecture - Views to present data and Controllers to pass data and commands back and forth between the Model and the Views - is very much a GUI framework.

  • What is confusing me is there Model (a layer representing entities and data access) in a pattern that exists to solve GUI! I do not see SRP here. – Maykonn Nov 9 '13 at 1:49
  • 1
    The Single Responsibility Principle was used to break up the traditional GUI that did all the heavy lifting of getting the data from the model, formatting it, presenting it, getting user commands and updating the model into discrete components that were responsible for one part of that process. Don't focus so much on the Model, think of it as a black box - the architecture is about how you get data from the Model (Controller), present it (View), get user input (View) and pass those commands to something that will update the Model (Controller). This is GUI bit - the Model can be anything. – Azrael Seraphin Nov 9 '13 at 2:20
  • Then the MVC architecture is about View and Controller. Really, now it makes perfect sense to me, or not - let's see: What is important for this architecture is the application UI and how it works with data from outside to inside and inside to outside the application.That way I can have teams working only in View and Controller (desktop UI, Mobile UI, another mobile UI, etc.), and teams working only in Model layer (applying architectural patterns as Domain Driven Design). Correct? – Maykonn Nov 9 '13 at 2:57
  • 1
    Correct, in practice the Model will have its own multi-layered architecture with database, object-relational mapper, and business logic layer. The Controllers interact with this to create easy ways to access and update the Model, passing the data to Views and commands back. Or indeed as you say, the "View" might not even be in the same project, it might be a mobile app that uses JSON data provided by a Controller. MVC just breaks the application up so each area focuses solely on the thing it is good at and can have further architectural patterns applied at that level as needed. – Azrael Seraphin Nov 9 '13 at 3:50
4

He is right.

The M in MVC says that there is some kind of "data", but it says nothing how those data are structured or retrieved. It can be practically anything from in-memory store to database to webservice.

There is also the V of MVC. Which is closely tied with UI. So if you use MVC for something else than UI, the V won't make much sense and then the whole thing won't make much sense.

  • I agree. But I'm still confused. So MVC is for GUI and Domain Model for the domain? And the relationship GUI->Domain should be given by a webservice that accesses the API provided by the Domain Model? But it seems to me that almost all programmers do wrong when using MVC for whole application (GUI, Domain Model, and some even Data Source). So MVC is only for the GUI? – Maykonn Nov 8 '13 at 23:24
  • What Euphoric is saying is that MVC pattern is concerned mainly with your Views and your Controllers. It is mostly mute about the Model, saying only that it contains data and behavior that is relevant to your problem domain. – Robert Harvey Nov 9 '13 at 0:01
2

MVC isn't a GUI pattern, it's a common pattern to decouple a model from how it is viewed and controlled. I've seen it used for game servers where varied controllers (people, ai opponents, network players) and varied views (simulation mode, over a network, right to screen) need to share a common model (your game objects).

To take any tool and typecast it to only that one role will only prevent you from using it to solve other, similar problems.

  • 1
    That's not what a controller is, if you're referring to the C in MVC. A controller is a software object, not a user or agent. That's not precisely what a View is, either. – Robert Harvey Nov 8 '13 at 23:58
  • In this point of view MVC is the entire application. So I can consider the following sentence an MVC architecture?: VIEW is just client code (javascript, ajax, desktop UI, Mobile UI), which consumes through an CONTROLLER (webservice), the MODEL (which is completely detached from the Views - desktop UI, Mobile UI - and on another server). Thus, VIEW and CONTROLLER not have any relation with the Domain. – Maykonn Nov 9 '13 at 0:00
  • @Maykonn: I suggest that you write a simple MVC program or two. Once you have used the architecture, its purpose will become very clear. – Robert Harvey Nov 9 '13 at 0:02
  • 1
    @RobertHarvey - certainly, but the point of decoupling these components is so that they can be dropped out for alternative implementations (like the examples I describe). – Telastyn Nov 9 '13 at 0:10
  • 1
    In MVC a controller is a "switchyard" of sorts; it mediates requests between the View and the Model. If that is what you mean by your answer, then you've written it in a confusing way, because what you're describing as controllers are really users. – Robert Harvey Nov 9 '13 at 0:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.