avatar

Andres Jaimes

The Rationale behind the Creation of a Model-View-Controller Framework: Fantastic

By Andres Jaimes

Important: This is a work in progress document.

The Model-View-Controller is a software pattern frequently used for web development. As its name states, it is composed by three components:

  • A Model or domain representation of a problem. It receives commands, processes them and modifies its state according to the input provided.
  • A View whose main task is to retrieve information from the model and turn it into a useful representation for the user.
  • A Controller that waits for user commands and translates them into appropriate model requests.

These three components work together the following way:

TODO: Image

The most famous MVC frameworks for Java are Struts 1, Struts 2 and Spring MVC.

Fantastic

The final purpose of this document is to create a Java MVC framework, named Fantastic. This framework will be able to perform most modern operations required by modern web sites.

This framework will consider the following:

  • Model classes will be independent from other frameworks to the greatest extent. The intention of this point is to achieve reusability and easy class testing.
  • Model classes will receive, to the greatest extent, all its parameters using the standard parameter passing convention, in order to get predictable results.
  • Specific functionality will be added thru annotations. They will keep the model classes clean and reusable.
  • A model that allows developers to create REST like web services.
  • A controller that turns GET and POST requests into function calls.
  • A small configuration file.

The Model

A model is a representation of a particular business domain. It can be represented with by a simple class, for simple examples, or by dozens of them.

A model performs all the required functionality of a business domain. It responds to the commands sent by the controller and provides the view access to its state.

Since a model is very specific to each business domain, and we cannot create a general solution for it, the framework will provide a set of features that allow the model interact with the view and the controller.

These features will be provided as a set of interfaces, abstract classes and annotations that allow easy reusability and testing.

A typical model class will look like the following:

public class UserAction extends Action {

    @GET ("/users")
    public String showForm() {
        // display a form
        return "user.form";
    }

    @POST ("/users")
    public String saveUser(User user) throws ActionException {
        // Save user
        // DAO.save(user);
        // display the user information
        return "user";
    }
}

The previous code shows the following features:

  • An abstract base class named Action. This class implements basic functionality and is independent of any web framework.
  • Annotations link each function to a predefined GET or POST request type and a URL.
  • Values read from an HTTP request are transformed by the controller and turned into regular function parameters.
  • Model functions return a string. This is mapped by the controller to a JSP file.
  • The class can be easily tested and is independent of web related classes.

The View

A view is a class or set of classes that generate a visual representation of the related model. A common way to implement them is via JSP files. The importance of having a separate set of view classes has been discussed and is clearly defined by the Model 2 Java Pattern.

Views can generate different output types like plain text, HTML, JSON, XML, PDF, proprietary document formats like Excel, Word, etc. The type of output to get is usually set by the user request.

This framework will include common functions that allow developers generate content from the model state.

A typical view JSP file will look like the following:

<!DOCTYPE html>
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <title>JSP Page</title>
</head>
<body>
    <h1>User Info</h1>

    <strong>Name:</strong> ${user.name}<br>
    <strong>Age:</strong> ${user.age}<br>
    <strong>Enabled:</strong> ${user.enabled}<br>
    <strong>Date:</strong> ${user.date}<br>
    <strong>Favorites:</strong> ${user.favoritesAsString}<br>
    <strong>Uploaded File:</strong> ${user.file.submittedFileName},<br>
    <strong>Size:</strong> ${user.file.size} (${user.file.sizeInBytes} bytes),<br>
    <strong>Content Type:</strong> ${user.file.contentType}<br>
    <strong>File Name:</strong> ${user.file.fileName}
</body>
</html>

Views are also dependent of the business domain. So it is not possible to create a generalization of them. However a set of functions that allow an easy interaction and rendering of a given model are available.

The Controller

A controller is a set of classes that receive web requests, modify them and turn them into commands or actions to the model. The controller is considered business domain independent, since most scenarios work in the described way.

Framework Configuration

To avoid long and complex configuration files, this framework will use annotations. They have to be kept simple so the code does not turn into an annotation mess.