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.
Rafael Victória-Pereira has more than 20 years of IBM i experience as a programmer, analyst, and manager. Over that period, he has been an active voice in the IBM i community, encouraging and helping programmers transition to ILE and free-format RPG. Rafael has written more than 100 technical articles about topics ranging from interfaces (the topic for his first book, Flexible Input, Dazzling Output with IBM i) to modern RPG and SQL in his popular RPG Academy and SQL 101 series on mcpressonline.com and in his books Evolve Your RPG Coding and SQL for IBM i: A Database Modernization Guide. Rafael writes in an easy-to-read, practical style that is highly popular with his audience of IBM technology professionals.
Rafael is the Deputy IT Director - Infrastructures and Services at the Luis Simões Group in Portugal. His areas of expertise include programming in the IBM i native languages (RPG, CL, and DB2 SQL) and in "modern" programming languages, such as Java, C#, and Python, as well as project management and consultancy.
MC Press books written by Rafael Victória-Pereira available now on the MC Press Bookstore.
 |
||
 |
|
Evolve Your RPG Coding: Move from OPM to ILE...and Beyond Transition to modern RPG programming with this step-by-step guide through ILE and free-format RPG, SQL, and modernization techniques. List Price $79.95 Now On Sale
|
|
||
 |
|
Flexible Input, Dazzling Output with IBM i Uncover easier, more flexible ways to get data into your system, plus some methods for exporting and presenting the vital business data it contains. List Price $79.95
Now On Sale
|
|
||
 |
|
SQL for IBM i: A Database Modernization Guide Learn how to use SQL’s capabilities to modernize and enhance your IBM i database. List Price $79.95
Now On Sale
|
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online