Does MVC pattern negate other design patterns?

Question

So usually when working with the MVC you have a controller that controls the input a model that process it and makes it ready for the user and a view that display the "result" to the user.

Now when creating this pattern you seperate the code into their relevant place. for instance the controller code goes into the controller, the gui code goes into the view and so on.

Now my question is if we look at all of the design patterns out there for instance the observer pattern. How would you apply such pattern to a code structure that already implements the MVC pattern? for that case many of the other patterns aswell such as composite, factory and command pattern?

Doesnt the structure of the MVC pattern make it harder to implement other good pratice design patterns?

Answer 1

First thing you should note, that MVC is a UI-related pattern. It took me several years to get this pattern understood correctly. MVC also, is not a real pattern, it is more like a general approach, because various implementations exist.

For example, the Model-View-Presenter is an incarnation on MVC pattern with slightly changed responsibilities, very suitable for desktop applications. In any case, the presenter in this approach would implement an observer pattern, and the view is observable object. Moreover, usually, when the view is somehow complex, I would introduce a ViewData object, or so-called ViewModel, which contains the data being displayed and inputted by the user. That case view also becomes an observer for this ViewModel object.

In case of large desktop application, you couldn't stay with good code using only MVC pattern. There will be too much responsibility for each layer. That case MVC is just a top of the whole application. I would say a small example from own experience.

All business logic implemented by Commands, Commands returned by CommandFactory (factory pattern). There also orthogonal logic for commands, like checking access rights, and logging of business actions executed. This orthogonal part intensively uses Decorator pattern. In the middle of application there is a model of current data state, which is not a simply database-mapped model, but model that have behaviour related to business processes under the hood. This model is a bunch of Observable objects, which observer by the UI layer (MVP pattern). Exact object creation and lifetime is controlled by ServiceLocator/Dependency Injection patterns.

That said, when an application grows larger and larger and become more complex - you have to split it in parts, that are as independent as possible, so you could involve more people on a project. To reduce the complexity, and do not suffer from a NIH syndrome (Not-Invented-Here) there are plenty of patterns which give you a way if implementing a solution for typical design problems that is well understandable by other programmers.

Answer 2

The MVC pattern is a composed pattern consisting of multiple patterns:

• The Model uses the Observer pattern to keep the view(s) and controller updated.
• You can find the strategy pattern in the view and the controller as the view is only concerned with the visual aspects and delegates all the interface behaviour to the controller
• And you can find the composite pattern in the view if working with nested windows etc.

So to answer your question, the MVC already almalgamates quite a few design patterns and this raises the complexity as is not even mentioning adding more patterns.

** edit **
Kind of started reading up a little and found a little more information on the subject.
If you do need some more patterns or a different approach to MVC patterns their seems to be a whole family of patterns that either adapt, replace or add patterns to the existing MVC for all sorts of situations:

• MVC,
• MVA,
• MVP,
• PAC,
• Model-Delegate

Answer 3

No, because most design patterns don't dictate how the code should be organised. Instead they describe the roles that classes can have in a particular interaction and give common names to those roles to ease communication with other developers.

The fact that the MVC pattern suggests a certain organisation of the classes does not mean that you can't apply other design patterns within or across that organisation.
For example, within an MVC triad, you can use the Observer pattern to let Model classes inform the relevant View classes about updates to the Model. This is entirely within the structure of the MVC pattern, because the Model does not have any knowledge about which View classes it needs to inform, only that it should inform those classes that are registered (and they can be View classes, but equally well, they can be other Model classes).
In a similar way, you can also use the Abstract Factory pattern to create specific View classes based on parameters that the Controller should not care about (for example, if you have a separate View class for each supported language).