If the previous TechTip left your head spinning with all that MVC stuff, this one will help. I’ll explain each layer of the model.

It’s now time to dig a little deeper into the MVC and talk about each layer.

The Model Layer

According to IBM’s Lab-Based Services and Training (LBST) application modernization team, the model layer consists of the following:

• Tables that contain persistent data
• Table Data Access Objects (DAOs) that represent interfaces to the data tables
• Data Access Object Views (DAOVs) that represent SQL view interfaces and business logic
• Stored procedure definitions for each of the view interfaces

The stored procedure definitions are of paramount importance because they’re the method by which the controller layer accesses the model layer.

Each DAO is represented by a service program for business interactions. The model layer shown in Figure 1 uses SQL to access persistent data and defines a set of data structures as the interface parameters. These data structures are externally described by the data model, table data access, and view data access.

Figure 1: The model layer is shown here.

There are various tiers in the model layer:

• The SQL view is built over existing database tables.
• Data Access Object Tables (DAOTs) are implemented as RPG service programs with external procedure definitions that are accessible from the DAOV.
• The DAOV accesses data through the DAOTs. Access is gained through a set of “verbs” in the form of procedure names that are used by the business object layer to manipulate the DAOs, such as the Rtv_Item_Description, Rtv_Order_Delivery_Date, or Wrt_Order_Record examples from the multi-tier architecture implementation earlier in this subseries.
• A set of corresponding APIs has access to database tables via SQL commands (i.e., Insert, Update, Delete, and Select).
• The service programs, shown as the top layer of the DAO architecture in Figure 1, are the callable interfaces used by the controller layer.

The data model interface is provided through DAOVs. Each DAOV is implemented as an RPG service program with external procedure definitions that are accessible from the controller layer. Each representative object contains a data object in the form of RPG externalized data structures or SQL views.

The business object has a set of “verbs” in the form of procedure names that are used by the presentation layers to manipulate the business objects. The common verbs for the design are Get (or Retrieve), Add (or Create), Update, Cancel, Delete, Is, and Validate (or Check). Where possible, the business logic should be built into the view definition. When the business logic can’t be represented within a view definition, an SQL function might be defined, or a stored procedure might be implemented as a wrapper around the RPG procedure. The method used depends greatly on the function performed by the RPG procedure because it’s not always viable to migrate all business rules to SQL. Even if you were an SQL expert, there are some business rules so complex that they’re simply too time-consuming to re-implement in SQL.

You probably noticed there are some similarities between the MVC approach and the ILE modularization approach I’ve been preaching for a long time now in the RPG Academy TechTip series. This is not a coincidence. The MVC approach is a solid design standard, but it’s often misunderstood by RPG programmers because it seems too alien to wrap your head around. If you’re still feeling that, just keep reading. It’ll become clearer later.

The Controller Layer

The purpose of the MVC’s controller layer is to support operations performed on data. The controller provides model data to the view and interprets user actions such as button clicks. In other words, this MVC layer is the equivalent of the main flow in the multi-tier architecture implementation presented earlier. Because of its function, the controller layer depends on both the view and the model layers. As it acts as a “man in the middle” between the two other layers, any change to the model or the view layers will require some sort of adjustment to the controller layer.

The specifics of this and the view layers depend directly on the technology you choose to implement. For instance, in a “pure” IBM i environment, the controller code is the part of the program that contains the workstation file, the execute format operations, and other code that manipulates the UI. This includes setting indicators, loading subfiles, and decoding function keys and options. It’s hard to separate it from the view layer, explained next.

The View Layer

The view layer provides an interface to view and/or modify data. A broader definition says that the view displays the model data and provides user actions (such as button clicks and form input data) to the controller.

The view layer can be independent of both the model and controller, or it can act as the controller and therefore be dependent on the model. It all depends on the technology used. For instance, if you choose to implement a UI using RPG Open Access, your view will be the handler program.

Coming Up

That’s all the time I have for now. In the next TechTip, I’ll discuss how to reengineer an ILE program, using the MVC design pattern.