A Java Model View Controller example (Part 1)

After writing several recent Model/View/Controller (MVC) pattern articles (A Model View Controller diagram, Model View Controller definitions), I thought it might help to share a real-world implementation of an MVC design. To that end, I’d like to share some information from a Java/Swing GUI application I wrote several years ago to help me in my work with Function Point Analysis (FPA).

A Java MVC example: My sample application

To help you understand this MVC example application, here are two screens from the application.

In this first screen — which is the “main” frame of the application — you can see from the tabs on this frame that the application centers are three FPA concepts: Entities, Process Groups, and Processes. There is also a fourth tab in the application that provides access to all the reports the application generates.

In short, this application lets you define high-level “Process Groups” in a software application. Then, within each Process Group, you identify the detailed processes in a given application. For instance, the application I was analyzing at this time has processes like “Add User,” “Edit User,” etc. (Processes are like UML use cases.)

When the user presses the “Add Process” button on the main frame of the application, an “Add Process” dialog is displayed, as shown here:

As you can see, this dialog lets the user add a new process to the system. This dialog shows some of the fields that make up an FPA process.

How a Model View Controller (MVC) application is built

Now that you’ve seen a little bit of what the application looks like, we can look at how the Model View Controller design pattern is used in this application.

I’ve organized this application so each main tab in the application has its own subdirectory in my Java project. Following Java conventions, I have a root-level project folder with this package name:

com.devdaily.fptracker

where “FPTracker” is the name of my application. And then, within the fptracker folder of my application, I have the following subdirectories that correspond to the four tabs of my application:

• entities
• processgroup
• process
• reports

Next, drilling down into just the process folder of the application, this folder has the following sub-folders, and the following Java classes:

• model
  • Process.java
• view
  • MainProcessPanel.java
  • MainProcessTable.java
  • MainProcessTableModel.java
  • EditProcessDialog.java
  • ProcessReportPanel.java
  • ProcessDetailReportPanel.java
• controller
  • ProcessController.java
• dao
  • ProcessDao.java

At this point I think you can start to see the MVC layout of this application; I’ve intentionally created three different directories here named model, view, and controller, to help me partition my application into these components. I’ve also added a fourth directory named dao to store my “Data Access Objects” (or DAOs; more on this shortly).

MVC pattern: Component descriptions

Here’s a brief description of the most important classes in this “process” part of the application:

ProcessController The ProcessController is the coordinator for the “Process” portion of my application. When the user works in the Process tab of the application, the ProcessController handles the interactions with the user, displaying dialogs, working with other controllers, and updating Process-related data.

Process The Process class in the model directory contains the attributes and many of the behaviors that make up the concept of a “process.” As you can see from the Add Process dialog, the attributes of the Process class include processName, processGroup, processType, numFtrs, numDets, complexity, etc. As an important note here, the complexity field is a calculated value; it doesn’t stand on its own, but it is calculated from the Number of FTRs and Number of DETs values. This shows some of the behavior and domain knowledge of the Process class.

MainProcessPanel This is the view that the user sees when they select the Process tab in the application. This panel (technically a Java JPanel) contains a scrollpane, and that scrollpane contains the MainProcessTable (a Java JTable).

EditProcessDialog This is the dialog that is shown in the second figure above, and it lets the user either add a new process, or edit an existing process (depending on how it is invoked).

MainProcessTableModel It may seem weird to have a class with the "Model" name in the view directory, but this is more of a Java artifact than anything. The Java TableModel class is essentially an adapter class, adapting your model (the model/Process class) to a form that conforms to the model a JTable can work with. While it is arguably a model class, it is a Java model class created specifically to work with a Java/Swing JTable, and won't be of any value to you in a web application; think of it as an assistant to the JTable view.

ProcessDao This is my Data Access Object for the Process entity. This is a special class which knows how to read and write Process objects to the database. Many modern applications and frameworks (think Ruby on Rails, Hibernate, or CakePHP) encourage placing database-interaction code in your model classes, but I tend to put my DAO classes into a separate directory like this. (Conceptually, the difference is (a) my ProcessController tells my ProcessDao to save my Process to the database, while (b) in a Hibernate-based design my ProcessController would tell my Process object to save itself to the database. There are pros and cons to each approach.)

On to "A Java MVC Example, Part 2" >>