Java – Implementing MVC pattern in SWT application

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.

I see another method that, unless I've misunderstood your post, hasn't been mentioned:

The main view, post, would have its model. This model would consist of ONLY the properties necessary to display this post (author,title,body, etc). Then, every piece of the post view that you can think of (timeline, tag navigation panel, subscribing panel, etc), would be split into their own views and each one would have its own model. This way, you can build up those models in your controller when you need them.

It might sound like an unnecessary amount of extra work to split these out like this, but it lends itself to the single responsibility principle. Keep each "view/model" focused on itself so that it can be re-used anywhere it is needed.

If you feel that your code is beginning to duplicate itself, which it might depending on your situation, you should consider writing some sort of "helper class." This helper class would handle all of the model build-up in one place, and all other duplicate code would be stripped down to a helper class call.