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?
Best Answer
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
ViewDataobject, or so-calledViewModel, which contains the data being displayed and inputted by the user. That case view also becomes an observer for thisViewModelobject.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.