Model-View-Controller-Interactor

Why MVCI???

#

So, yeah, why another framework?

All of the frameworks that you are familiar with, like MVC, MVP and MVVM are actually quite old. I’m not going to say that they predate Reactive programming, because I have feeling that this too is older than you might think. But they certainly do predate JavaFX, and the way that JavaFX implements Reactive programming.

First of all, forget about Model-View-Presenter (MVP). It’s completely irrelevant to JavaFX unless you are attempting to use FXML in an extremely restrictive way.

Next, Model-View-Controller (MVC) has a paradigm where the View is allowed to see changes in the Presentation Data (which is part of the Model), but all changes to that data from the View must go through the Controller. This is a big problem for Reactive JavaFX because it means that you cannot bidirectionally bind your Presentation Data to the screen Nodes since this would bypass the Controller for updates from the View.

You can just ignore this restriction if you want - there are no MVC police to arrest you, after all. But this is a pretty central concept to MVC, and if you just toss it away then you’re not really doing MVC any more.

Finally, Model-View-ViewModel (MVVM). On the surface, this seems to be a better fit for Reactive JavaFX. After all, it is specifically designed to allow binding between the Presentation Data and the View. However, just like MVP, it tries to reduce the View to a simple layout, absorbing all of the View logic into the ViewModel. At the same time, it has a problem at the other end. The Model isn’t allowed to know about the implementation of the Presentation Data, and the ViewModel isn’t allowed to know about the implementation of the Domain Data. This means that you need an extensive interface between the ViewModel and the Model to transfer data between the two.

Nobody Really Understands MVC, MVP and MVVM

#

My experience is that very few people actually understand how to use them properly. And if they did, they probably wouldn’t want to use them.

In my opinion, the biggest issue is with them “Model”. It’s simply counter-intuitive.

Virtually everyone - and this includes almost every on-line tutorial I’ve ever seen - treats “Model” as virtually synonymous with “Presentation Data”. Now, in MVP and MVC, the Model includes presentation data, but in every framework the Model encompasses “Domain Knowledge”.

What is “Domain Knowledge”?

Domain Knowledge is the context for your application, the stuff related to what it does. If this is an sales application, then it contains the information about customers, inventory, invoices and the databases that store that information. It contains knowledge about API calls, and contains shared logic that is used across different screens in your application. If this is a game, then it contains the game logic, access to database that contain saved data and API calls to remote systems if they are needed.

Now, if you interpret “Model” as “Presentation Data”, where do you put the database and API calls? It ends up going in the Controller, or the ViewModel.

I’ve seen this time and time again in online tutorials. Most often, the “Domain” part of the Model is just left out. The examples are too simple to have any “Domain”, so the Model just contains Presentation Data and the domain can be ignored.

Model-View-Controller-Interactor

#

Enter MVCI, the framework that evolved as I struggled over years to build real systems while following MVC (or what I thought was MVC). I was left to figure the hard parts myself, and I fixed issues with my approach on at a time.

The result is a framework that meshes extremely well with JavaFX. It makes sense, and it leverages JavaFX’s Observables and Bindings in a way that feels natural:

1. The View is a complete GUI, not just a layout.
2. The Interactor handles all of the Domain Knowledge, and can access the Presentation data.
3. The Controller co-ordinates all of the actions and threading, and provides the link to the rest of your application’s GUI.
4. The Model is strictly the Presentation Data, implemented as JavaFX Observables.

I’ve used MVCI for years now, and I have yet to encounter an application that did not become significantly simpler and easier to maintain (or to write in the first place) by using MVCI.