different styles of implementing Model-View-Controller in Java

Question

//update 1: so, unfortunately there's not much activity on this topic than I hoped for - more down the bottom

first of: I know this topic is often overrun and hence suffer from personal opinions and therefore often gets closed as off-topic. So, I'll try to keep it objective. I hope this prevents me from getting "locked off".

When you look at Wikipedia, it says basically this: The user directly interacts with the controller, the controller manipulates the model and the model updates the view. When searching on Google one finds many different other types:

• one for example states that the model is always on its own and doesn't know anything about the others
• another one says that the controller is kind of the glue but model and view doesn't know each other

This goes on for pretty much any combination of these three in addition with some "extras". So, as I see it: There seem not really one (the right) way to implement MVC but rather some different approaches all follow the same base principle.

So, the way I want to try to keep it "objective": Are there some specific reason to go one approach or another? Is there any advantage on using one of the three as glue for the others? Or all knowing each other in some way?

When using Swing one already uses some form of MVC - some source called it "model-(ui)delegate" where View and Controller are combined backed by a model. Is it worth try to reproduce this style as one already working with Swing?

Maybe to light it up a bit: I currently want to develop an API client for Mixer (yes, I have topics about YouTube and Twitch, but currently Mixer seem the best platform for me and my needs) and struggle a bit on how to approach the separation of the data (Model), the GUI (View) and all the glue in between (Controller?). In the past when I wrote some of my small tools I didn't got any better than what's known as spaghetti code. But as I want to maybe publish it (I already started by using a public GitHub repo) or provide it as a service (so others use my client on my project) I thought to structure it by some established principles.

So, rather than seeking for personal opinions (as this seem to not liked be seen here) I rather ask for some objective information about specific ways of actually implementing the MVC in Java with their pros and cons.

Thanks in advance and apologize to any moderators may now think "not another one of those".

//edit 1: So, although there wasn't much activity on this topic in the past weeks I wasn't doing nothing but kept a bit of more "researching": From what I found I got this: No matter if one deals with only some local GUI based application but may also what I plan different types of Views and event sources over the network it comes down to interconnecting a few classes which, by the principle of separation of concerns, all are only do one specific task. I found some examples where the View was only seen as a GUI, others also extended it to console and even printers. So, a seeing a View as the only source of input may not be the best idea but see it as something that displays the data only. The controller input on the other side may could also be implemented as a GUI, and maybe even combined with the View displaying the data, but should be at least modular so it could be interchanged with other types.

The way I want to try to implement it is event driven so that "actions" happen based on when an event is fired (how an event is generated and then fired may is for another topic). I've seen many examples using the Observer pattern for this - so basically a mix of Observer and MVC (at least as far as I understood them). Could this be a possible way of implementing it:

• some input to generate input events (maybe a GUI, maybe a console, maybe network input) coupled to an input controller
• a model contain the data and logic to modify them, maybe also having its own model controller
• the view as output-only manipulated either by a main application or its own view controller instead of register itself as an Observer on the model
• an overall application controller as the glue between the other controllers with some glue logic

By this plan the basic application startup would look like this: main() first creates the main application controller with just empty lists for all the others, then the model(s) (or model controller which by it creates the model) and link the model controllers with the main controller, and in the end the view and also linking it with the main controller. Finally, after this is all done some "entry point" on the main controller is called to start it all of.

Anyone have some input on this idea?

Answer 1

There is one pattern that i follow in most of the projects, and is inspired by Spring Boot MVC, SOA, and many frameworks of UI like JSF.

1- Your views if any should always be dumb components they took the data from controllers formatted and ready to be displayed, they don't maintain a state.

2- Controller or view model, should provide the views with the data they need and maintain their state in a way that's suitable for view but don't do the actual work of the service, it just format the data in the way suitable for the views. controllers can get this state or data from model through services.

3- The model layer is responsible for the state of the domain objects that may come from data store like a database, once they got the data in a way suitable for service or to apply CRUD operations on, their role is finished, the model don't know anything about the controller or the view, the model don't care if their is no view at all.

4- One good approach to go with is to encapsulate your core business logic in Services if needed. Services contain the core business logic, and you can follow SOA principles do design good services along with design principles like SOLID, DRY, and some design patterns. Services should always be clean and designed well so the app don't fail by changes, they can do all the work and provide results that suits any UI not just a specific controller or UI that's why you should follow SOA principles.

So what is the difference between model and view model/controller ? the view model gives the view what they need ... see this answer, for more clear explanation

For the API part, to make sure it's clean and reusable follow the design principles related to what you will use, for example if you will use REST, there are conventions and best practices to make sure your API is clean and well-designed.

In a nutshell, Think about the single responsibility of each layer and class. You build your model and services first and they should be closed for most of modifications. Start use them as if you are using them through API so build your controller to use them.

You need a lot of things to avoid spaghetti code anti-pattern. If you want good resources to learn about this, you can read clean code, clean architecture books, and some design patterns and refactoring techniques from the head first design pattern book and/or refactoring.guru or any other source you are comfortable with. This topic is so wide and have a lot of things to say about.