Should I always use the MVC pattern (or similar) for big, graphical and professional applications?

Question

If I write an application and decide to develop only a single graphical interface for it, and never intend to develop multiple GUIs, then by today's standards it is okay not to use the MVC pattern or MVP pattern, or should you generally prefer the MVC pattern for object-oriented software with output? The advantage of the MVC pattern is precisely that of being able to program many different GUIs. However, if you plan to develop only a single GUI from the start, this advantage will be eliminated.

Answer 1

The advantage of being able to program to many different GUI's is minimized if you only have one GUI. But understand that you have multiple GUI's if you ever update your GUI.

The point of decoupling isn't simply ability to work with multiple components. It's that that the other components can change without impacting the rest of the system. So if you're looking for a situation where you can disregard these advantages you need a better excuse than your magical ability to predict that there will never be "multiple GUI's". You need to also predict that the one you make will never need to change.

You certainly can do this. I know I've written plenty of "untestable" throw away code before. Just own up to what you're doing.

Answer 2

The primary point of MVC and related architectures is to structure the flow of data and behaviour in your application. In particular, we want to separate the presentation of data from internal representation and business logic because that makes it easier to work on the GUI or on the business logic. There may be other benefits (such as reusing business logic, or better testability), but those are secondary.

In some small cases you will be fine without these patterns. But for a more complicated program, you will need a clear architecture to avoid a “big ball of mud”. MVC/MVP/MVVM are a few popular choices for that architecture. Decoupling the external interfaces from internal logic is such a great idea, it's even used outside of GUIs.

Answer 3

First, I applaud your approach to consider the trade-offs, even for things that seem dogmatically part of our thinking nowadays.

Short answer: Yes, absolutely, if you know what you are going to do, there is absolutely no reason to artificially separate things that naturally belong together. Like objects and their representation on the UI.

Long answer: Depends on what you mean by MVC. If you mean the usual meaning nowadays, to have a pure data structure ("Model") that some procedures ("Controller") shovels back and forth, then these will definitely not help you. In fact, this will make your application significantly harder to maintain, since any modification in the actual "business" object will exponentially propagate through these structures.

However, doing everything in the objects would be also wrong. The objects should have just enough display functionality to not have to allow external objects access to their internal data, but not as much to have to deal with irrelevant details like color, font-size, things like that.