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.