Question

Introduction to the problem

I have been taught about OO Analysis and Design through Craig Larman’s Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, that follows the UP(Unified Process).

When using it, we usually draw a Domain Model and from it, doing Interaction/Association Diagrams, we get to the Class Diagrams. We generally then make Controllers that will be the "gate" between our Model and the "outside World" (following the GRASP patterns). All the world accesses to do any kind of logic has to go through the Controllers. I’ll call those Controllers Model's Controllers, so later when we talk about MVC's Controllers we can differentiate them.
That can be depicted in the following most awesome diagram:

alt text http://dl.dropbox.com/u/6187267/pic1.jpg

In black we have our Model‘s objects and that classes’ associations. In red we have the Model Controllers, that use data from the Model.

Basically, following this kind of design, you can only work with the Model through the so called Model's Controllers (we usually had one Controller per Use Case!).

Now the question itself

When learning about the MVC, I always had the question of wherever the MVC's Controller was in fact Model's Controller or not? Are they the same concept or not? I think they are different concepts, as the Model Controllers we used to do didn’t ever know about anything other than the classes on our Model, which is not what seems to happen in MVC's Controllers.

If what I’m saying is true, the following diagram should make sense:

alt text http://dl.dropbox.com/u/6187267/mvc_.png

Am I right?

Answer 1

I think I understand what you are talking about 🙂

What you are calling Model Controllers are known as Repositories. This is an interface that defines your specific interactions with the underlying model. For example, if you had a class representing Employees, and you wanted to do three things:

• List<Employee> List()
• Add(int employeeID)
• Delete(int employeeID)

Then you would define an interface called something like:

public interface IEmployeeRepository
{
    List<Employee> List();
    void Add(int employeeID);
    void Delete(int employeeID);
}

You would make sure that all your code deals with the Interface, and not the object directly – the Repository Pattern. This is what you are calling a Model Controller. See http://www.dev102.com/2008/12/08/working-with-aspnet-mvc-part-2-the-model-and-the-repository-pattern/ for more details, or search on Repository Pattern.

A contoller in the MVC world is actually something that dictates logic of program flow. For example, say you had a view of a list of employees. When the user hits “Delete” button on this view, the controller would load the appropriate repository and call the Delete method on it.

tl;dr: MVC Controller = When user does this, do this in a program (program logic); Repository (Model Controllers) = Define what interactions are supported with objects in my model

And yes, you’re right 🙂