MVC pattern implementation. What is the n-relation between its components

Question

Dear all,

I'm working in a C# project and we are , in order to get some unity across the different parts of our UI, trying to use the MVC pattern. The client is windows form based and I'm trying to create a simple MVC pattern implementation.

It's been more challenging than expected, but I still have some questions regarding the MVC pattern. The problem comes mostly from the n-n relationships between its components: Here is what I've understood, but I'm not sure at all of it. Maybe someone can correct me?

• Model: can be shared among different Views. 1-n relationship between Model-View
• View: shows the state of the model. only one controller (can be shared among different views?). 1-1 relationship with the Model, 1-1 relationship with the controller
• Controller: handles the user actions on the view and updates the model. One controller can be shared among different views, a controller interacts only with one model?

I'm not sure about the two last ones:

• Can a view have several controller? Or can a view share a controller with another view? Or is it only a 1:1 relationship?
• Can a controller handle several views? can it interact with several models?

Also, I take advantage of this question to ask another MVC related question. I've suppressed all the synchronous calls between the different members of the MVC, making use of the events and delegates. One last call is still synchronous and is actually the most important one: The call between the view and the controller is still synchronous, as I need to know rather the controller has been able to handle the user's action or not. This is very bad as it means that I could block the UI thread (hence the client itself) while the controller is processing or doing some work. How can I avoid this? I can make use of the callback but then how do i know to which event the callback comes from?

PS: I can't change the pattern at this stage, so please avoid answers of type "use MVP or MVVC, etc ;)

Thanks!

Answer 1

I´ve implemented the MVC pattern in C#. Don´t know very much about theory, or how it should be, or shouldn´t be. I just think that the pattern is the base idea, and then, you can use this idea in many different ways, depending on your own needs. I´ll tell you about my implementation, and hope it helps you.

**The Model**

Your description is pretty clear, so don´t have much more to said. Here is where I define my bussiness objects. I take advantage of this layer to include objects validation rules.

**The Controller**

In addition to handle the user actions and update the view, I have a Unit Of Work for each controller. I check that the objects in the view pass the validations (defined in the model layer) before commit changes in the Unit Of Work.

In my case, one controller can manage many models, and I like to have only one view in each controller.

Like a suggestion, I´d like to use my Framework with diferent UI, so I have an abstract implementation of Controller, and then I have specific controller implementations for different interfaces (WebForms, WinForms, ...).

**The Views**

In your case, we could call them, simply, the forms, the UI, ... I like to organize my desktop applications as if they were web applications, using tabs. One tab represents one controller, and so on, one view, and one or more models.

---

In conclussion, and in my case:

n models - 1 controller
1 controller - 1 view
--
n models - 1 view

Answer 2

You're probably over-thinking and over-formalizing it a bit.

Here's how I look at it:

1. Model: This is the actual thing that does real work.
2. Controller: This is the thing that sends inputs into the model, so it will do work.
3. View: This displays the results.

That's it. The easiest analogy to use is a console application - the app is the model, STDIN is the controller, and STDOUT is the view.

Extending that analogy, many GUI apps are built on top of command-line apps by attaching to STDIN/STDOUT. In that case, the things sending data to STDIN are the controller, the things taking data from STDOUT and putting on the window are the View, and the console app is still the model.

It's CS 101 again - input, processing, output. It's only trickier for a GUI app because the input and output are typically on the same window.

You (obviously) don't need to actually have a console app to do this - the separations can be done even in a single process. All the other weird wiring stuff that takes place is just whatever is needed to get this relationship between the parts to work. But the wiring isn't the important bit - the important bit is the separation of responsibilities and logical organization of the code.

So, whether 1 view must map to 1 controller, or any other orthognality issues are secondary. In fact, you should probably just do whatever your problem domain requires, but I'd (as typical) argue against over-eager generalization of code - IOW, don't mush things together that aren't really the same.

Answer 3

Model, View, and Controller are conceptual layers, not individual objects, so honestly it doesn't make a whole lot of sense to be thinking of them in terms of multiplicities. Nevertheless, I can try to approximate an answer for you.

• A Controller returns a single result for a single action; that result may be an actual view or it may be something else. However, the Controller doesn't really actually have any interaction with the view; all it does is provide one or two pieces of information in its result: The name of the view that should be used and (optionally) the model used to populate. It's up to the View Engine to actually create and bind the view, which is a considerable departure from normal Smart Client UI logic.

• A Controller may interact with several different pieces of the Model, or not interact with it at all in some cases; there is no rule for that side of the relationship. In an action result, a Controller has to give back either 0 or 1 instances of a "model", but this may not be the true Domain Model, it could be a View Model.

• A View is generally bound to exactly one Model (or View Model), although in some cases a View might simply be content and therefore not bound to anything.

So, in the very crude UMLesque parlance:

• Controller:Model = 0..* : 0..*
• Controller:View = 0..* : 0..1 (request) or 0..* : 0..* (overall)
• View:Model = 0..* : 0..1

This is all specific to ASP.NET MVC. If you were designing your own MVC implementation then obviously you could choose to implement it any way you like. Good luck implementing MVC in WinForms, though; Forms don't behave like Views at all, even patterns like MVP/MVVM are quite difficult (though not impossible, c.f. Microsoft's CAB/SCSF) until you move to WPF.