Time to introduce a conceptual (but rather useful) new tool for your arsenal: the MVC. No, it’s not a new type of vehicle! It’s the model-view-controller model.

The multi-tier architecture implementations shown in the previous TechTip are a step in the right direction, but they have its limitations:

• You’re still bound by the DDS limits—Your UIs will still be text-based and limited to a 24x80 or 27x132 green-screen resolution.
• Your code is not truly separated—Code for screen handling and control flow is still intertwined. It’s true that this approach makes it much easier to maintain, but you still have some code that is not where it should be. This also means that your “UI expert” also has to be the “control flow expert,” when these can be different tasks.

As you can see, this is not a perfect solution. It can work in a lot of situations, but to truly modernize your UI, for instance via a graphical user interface (GUI), you need to completely isolate it from the rest of the code. One proven way to do that is to apply the model-view-controller (MVC) paradigm to your IBM i application. Historically, developers, particularly developers of object-oriented languages, have used the MVC paradigm to implement clear divisions between various components of an application. The term components here refers to the more general definition, not exactly a module, but a group of code pieces of the same type: UI (presentation), processing (business rules enforcement and so on), and data access. The function of most applications is to retrieve data from a database and display it to the user, allowing the user to interact with the data and store updates in the database.

The MVC pattern was developed, as many other great things in IT, by Smalltalk programmers trying to determine the best way to couple event-driven UI objects with the classes that represent the state of the business model. This pattern was adopted by the Java community and incorporated into the Java Swing classes. Many other languages came up with their own implementation of the MVC, such as Microsoft’s ASP.NET MVC, for example.

In today’s fast-paced business world, UIs change much more frequently than the database portions of applications. While this is true for an IBM i-only application, it is even more true in a Web-connected application. Coupling the data and UI of a business application tends to require business logic that goes far beyond the application’s data transmission (or view). Following good design principles pays off when it comes time to make changes to an application’s structure, as you usually do in a modernization initiative. Web services and design paradigms such as the MVC, shown in Figure 1, go a long way in developing and maintaining applications that are feature-rich and capable of handling dynamic content, while supporting a rapid development model to match the business needs.

Figure 1: The MVC design pattern (adapted from Sun Microsystem’s original model)

The MVC design pattern splits a program into three layers:

• The model provides the business logic and data access capabilities of the application and exposes business services.
• The view displays and collects information from users.
• The controller intercepts input and translates it into actions performed by the model. In other words, it controls the main flow of the program.

The MVC is somewhat similar to the multi-tier model, but it separates the data access layer from the interface so that the view (i.e., the UI) can be easily replaced or expanded. In the MVC, changes to the model data are reflected in all interfaces, because all views are observers of the data. However, you can change the view (or presentation layer) without any impact to the other two layers. This design pattern also helps ease the maintenance burden by ensuring that changes to the business logic layer are less likely to break the presentation layer, and conversely, that changes to the presentation layer are less likely to break the business logic.

Where the modular approach allowed several RPG programmers to work on different parts (modules) of the same program, the MVC approach facilitates multi-disciplined team development. Developers can focus on creating robust business code without having to worry about breaking the UI, and designers can focus on building useful and engaging UIs without worrying about the language their colleagues are using to develop the business code. As I said before, the “UI experts” don’t need to know RPG at all; they just need to have ways to access the data. The MVC approach facilitates the use of the best tools for each aspect of the development process, such as using RPG for creating the business logic and a combination of HTML, CSS, and JavaScript for creating the UI.

As this is probably new for some readers, it’ll require some additional explanations for the concept of MVC to really sink in and become something useful. Over the next few TechTips, I’ll be talking about each of the layers and how to reengineer an ILE program using the MVC.

Until then, feel free to comment, using the Comments section below.