Design Overview

Source: Java BluePrints J2EE Patterns

AppTrac employs a Model-View-Controller (MVC) architecture. The main characteristic of MVC is that it separates the business logic (control) from the presentation logic (view). If done properly an almost complete separation can be achieved, in which case programmers can work on the system's control--how it functions--while graphic web designers can work on the system's GUIs--how it looks.

In an MVC design, the models represent the state information for the various entities that make up the system. For example, the StudentModel would store student data--e.g., name, id, etc.--while it is being used by the system.

The views represent the various screens that the user interacts with--e.g., the login form or the form used to edit a student's profile. The views can supplemented with templates, which all GUIs to be designed declaratively. For exxample, Apache Velocity is a Java-based template engine that makes it possible to achieve a clear separation between the business and presentation logic by using templates to describe Web pages.

Finally, the various controllers manage the entire functionality of the system. They display the appropriate pages and forms, process data input through the forms, and so on.


Contents

High-level MVC Overview

The following class diagram provides a high-level overview of the MVC design for AppTrac: Image:ClassDiagramOverview.gif

The DAO

The DataAccessObject (DAO) contains all of the systems DB queries. Its methods are called from the various Controller and Model objects. In a Java environment, the DAO would be the locus for Java Database Connectivity (JDBC) code that defines the interaction between AppTrac and the relation MySQL database. Any calls to the database would be made using pre-defined JDBC methods.

The DAO contains a contructor that sets up the database connection when invoked:

private <DBType> db;
public DAO() {
    db = ... // Code to make the connection to the database
}

Of course, if JDBC is used, its methods would be invoked to perform the handshake with the database.

The DAO contains a single method that makes all database queries:

public executeQuery(String queryString) {
   // Code to execute the query (using JDBC if appropriate)
}

The rest of the DAO methods simply construct specific query strings and invoke executeQuery():

public StudentProfile getStudentProfileData(String id) {
    String query;
    // Code to construct this query
    QueryResult = executeQuery(query);
    StudentProfile prof = ... // get student profile from query result
    return prof;
}

The Model

The Model class and its subclasses provide a computational model of the various entities that make up the AppTrac system. The Model superclass contains those model elements that are common to all entities. For example, since the models must interact with the DAO, the Model class should contain a reference to the DAO object. Its subclasses contain those instance variables that make up an object's state and those methods needed to manage the object's interaction with the system. For example, the StudentModel contains instance variables for name, system id, contact information, activity data any other information associated with student users of AppTrac. It would contain methods for constructing new students, saving a student's state to the database, getting a student's state from the database and so forth. None of these methods contain actual MySQL queries. Instead, they contain method calls to DAO methods (which themselves contain MySQL queries or call JDBC methods if JDBC is used).

For example, when a Student's profile is being edited, the constructor in the Student class might call a method in the DAO to retrieve student data:

...
public Student(String id) {
   student_data = dao.getStudentData(id);
}
...

The getStudentData() method inside the DAO object would construct the appropriate query, query the MySQL database, and return the retrieved data to the calling object.

Or if a new Student is being created for the system, the constructor might invoke the DAO to retrieve a unique system id:

...
public Student() {
   String new_id = dao.getUniqueId();
}
...

The View

The View class and its subclasses manage the system's GUIs. Essentially each view object is connected to an associated model object. For example, the various views associated with students would be associated with (and contain a reference to) the StudentModel. If a template engine is used, the view classes would have a reference to the engine. Computationally, the view classes get data from the model and display it in the GUI. If templates are used to define the GUIs, this step is mediated by the template engine. Similarly, for input, the view classes would receive data from the GUI (possibly mediated by the template engine) and pass it to the associated model.

A simple example:

public displayStudentProfile(String id) {
    StudentData data = studentModel.getStudentData(id);
    template_engine.assign("name", data.getName());
    template_engine.assign("phone", data.getPhone());
    ...
    template_engine.display("StudentProfileTemplate");
}

Note that the code in this and other examples is meant to suggest the sort of code that would make up the class definitions.

The Controller

For a Web-based application, the Controller superclass has an abstract method controlHandler(form_data[]), that is implemented for each Controller. The handler takes a parameter that supplies it with HTML form data (e.g., the GET array).

public interface Controller {
    public abstract controlHandler(form_data[]);  // Primary handler method
} 

The controller method would extract the data from the parameter and take whatever action is indicated. For example, for the LoginController, the handler method would be passed the user's username and password (from, say, the LoginView (HTML form). It would then call the appropriate methods to validate the user's password and direct the user to the appropriate GUI.