MVC in C#: Model - Controller relationship

Question

Normally I have one controller and one model. Is there a disgn-pattern to have 1 View with multiple Controllers and multiple Models. Where very controller can have multiple models, too?

Some links to related patterns would be nice.

Answer 1

I would recommend studying MVC more in general.

Answer 2

Generally a controller has only one model. However, you could create a composite model that itself has multiple models.

class CompositeModel
{
 private ModelA modela;
 private ModelB modelb;
}

And then have your Controller typed to that.

But if you don't know what you're doing ultimately that's a plan that'll only end in tears.

But if you can manage to avoid the God Model pattern it can be very powerful.

Answer 3

This would really only make sense when you have a model hierarchy (inheritance) where the view is showing the common properties of the various child models. Conceptually, this could work but as a practical matter I don't see this happen very often. In my code the only place that I approach something like this is with a Contact field. I have a User model that has a Self contact and an Emergency contact. Both contacts are of the same type with the differentiator being whether the relationship is "self" or something else. I have a single view for creating these contacts and that view is rendered by 2 different actions on the same controller -- CreateContactInformation and CreateEmergencyContact. Even this case, though, both use the same model -- Contact. I could have chosen to subclass the model, but there wasn't really enough of a distinction to warrant that complexity.

In the general case I would say that a view is used by a single controller and each controller deals with a single primary model. Ancillary models to the primary may be handled by the primary controller or have their own depending on how you want to structure the application.

Answer 4

There are other methods that been developed since MVC namely Model View Presenters. Here at Martin Fowler's website is a good overview of these patterns.

My own application uses a Passive View as it allows us to rip off a UI and substitute another easily. This an advantage for us as our software is a CAD/CAM application meant to be used with a varity of metal cutting machine.

Our forms are thin shells which call a UI Layer. The forms implement a interface and register's itself with the UI layer. We have a variety of forms used for different purpose. For example a setup form where the user modifies the extensive setup parameters for the machine he using, a shape entry form, a metal cutting form where the user positions the shapes to be cut. All of this forms have a distinct UI.

Also the metal cutting form is different between different type of machine. One may show a WYSIWYG view of a flat plate of metal. Another is a spreadsheet style grid of the parts to be cut in the order they will be cut. Another yet shows the parts positioned on a rotating pipe.

The UI Layer in turns takes the incoming input and executes commands. The commands in turn interact with both the UI Layer, and Model. Nearly everything is handled through command objects as opposed to direct calls through methods.

This structure allows a variety of UIs to be connected to the same model. Within a specific UI a variety of Views can be supported. What I have marked as Model could be separate libraries. They would only be combined at the UI Interface layer and above through the UI components referencing the different libraries.

The hierarchy looks like this.

• Forms Implement Form Interfaces
• UI Implement UI Inferaces and interacts with Forms through Form Interfaces
• Command interacts with the mode and the UI through the UI Interfaces.
• UI Interfaces
• Model