Java MVC Framework

This post describes a Java MVC framework I use currently on one of my projects. It is a very basic stripped down version, with no functionality whatsoever. But it is a useful starting point for some projects written in Java and it should save a couple of minutes in the future.

What is the Model-View-Controller pattern.

The Model-View-Controller pattern, or MVC, is a well known software design pattern, where the application’s features are separated into distinct entities with clearly defined goals. As the name suggests, there are 3 major parts of an application build with the MVC pattern in mind: models, views and controllers. There are other entities as well, such as model-view entities, used in larger applications. They are certainly useful, but not relevant in this demo.

The most important advantage gained is a thing called separation of concerns. By separating your application into layers, each one with clear goals to achieve, you can build medium to large and very large applications in a more controllable way. Change is more easily integrated (we all know how risky any requirement change is), bugs are more easily tracked and you can scale your application faster. A simple example is changing or adding another view (the application’s interface). This can happen for a number of reasons, a usability test for instance gave some concerning data and lots of things were ‘moved around’ by the designers. By separating the view, you can perform usability tests much earlier in the process and changing it is as easy as creating a new frame with different buttons on it. The view doesn’t know or “care” what’s going on in the background and it can be replaced easily.

I am biased. This tutorial is aimed at Java for the sole reason that I had to build my own MVC framework. I know there are plenty frameworks out there but there isn’t a definite ‘best one’ and I couldn’t justify the time to learn how these worked when I could easily build my own. Also, I have plenty of experience using ASP.NET MVC where the MVC pattern is basically forced on you. So I am used to build with MVC in mind from the very beginning. However, I never paid too much attention to how this pattern was achieved, it was “just there”.

Java however lacks a built in MVC pattern and you have 2 options: use a framework or build one yourself.

So here we go. Let’s build a Java MVC framework!

Models, as the name suggests, are abstract contraptions that exist to represent something used within the application. They store a list of properties that represent a “state” and, when this state is changed by the controller, it notifies the relevant views about it. A view is the application’s interface. It’s not necessarily a graphical user interface aimed at human beings, but can be an interface that connects to another application. Whatever the case, the view’s purpose is to deliver the output.

And finally, a controller is the heart of the application: it makes sure the application does it’s job. When receiving an input from the user, the controller is notified, who will make the necessary decisions and changes: update models, do some calculations, call some databases… Basically transforming input into output. A single master controller should suffice to most applications, although there are other techniques that involve multiple controllers, each controlling a subset of models and views. I personally prefer a singleton pattern when creating a controller (notice the private constructor.

Separation of concerns, we hear this all the time in software engineering. But what does it really mean? It means you should plan your application into so-called “layers”, each focusing on one thing and one thing only. The view for instance should not be concerned at all about what the application does or how it does it. It’s job is to display information and receive input. No processing, no thinking. Just receive and deliver information from and to the user. It will only communicate with the controller. When an event fires, that information is sent (preferably as raw as possible) to the controller. The controller then does it’s job and, based on the input, will perform some changes to one or more models. Now comes the tricky part. The model does not know anything about the view (it’s replaceable and dynamic after all) . But how does it notify it about any changes that just took part? The observable interface helps us out here. The model can send events to all ‘listeners’ about any state changes that were performed. The model does not know who listens and does not care. The view however does and will update itself based on the change that just happened. This cycle happens all the time, every time you add an input to the application.

Using utility classes

It’s a good idea to store all strings/styles/preferences from your application in a static resource file. Why? Because you may want to scale your application to another language. Changing the language used within the application will be a breeze if that is the case. Also, it’s so much easier to correct some obscure misspelling somewhere in your app, you know where it is already.

When dealing with databases or some sort of data sources (like external APIs), you should use a specific class that deals with it. Do not call a database from a controller ( or worse, a model/view ). It’s just bad practice. You may want to change your data source in the future. Instead, create a repository interface that your controller will use. If you need to change the database or API calls, you know where it to work on. You can (and should) have multiple repositories for all the data stores you use. When dealing with multiple data sources, I prefer to build a “universal” repository that deals whit what class to use for what API.

Weaknesses

There is a small weakness in this framework that I should mention. At one point, the controller makes a decision to update one of the model proprieties. Unfortunatly, I haven’t come accross of a sure way to link a proprety name with it’s relevant set method. I use a method called reflection at the moment to solve this, but you have to be careful to manually sync the property name with a string. Comments on this are welcome.

Conclusion and download

So here it is! The Java MVC framework, all saved on github. Feel free to suggest improvements and offer suggestion to expand it. Also, please comment if you have any questions about my post or the project.

Find it on Github

Screenshots

Java MVC Framework

Related posts

Comments are closed.