Want to make your big ol’ RPG programs more modular and easier to maintain? Then give the MVC design pattern a try.

Editor’s note: This article is excerpted from chapter 24 of 21st Century RPG: /Free, ILE, and MVC.

Model-View-Controller (MVC) is a design pattern. Unlike many of the design patterns that have been defined, it is not uniquely oriented to object-oriented (OO) programming, but can easily be used with procedural languages as well.

Nor is it related to some sort of programming or communication issue. Instead, it is uniquely suited to the types of applications we run in the business world: applications where we access data, display it somewhere, make changes to it, take it back in, edit it in various ways, and write it back out to the spot it originally came from.

Now before I go any further, I want to make one thing clear. When I use the term “MVC” I am using it in a generic, not specific sense. That is, in a specific sense, MVC is a very specific design pattern that has very specific requirements and attributes.

It is actually part of a family that is loosely called “MVC.” This family consists of MVC plus MVP (Model-View-Presenter), MVA (Model-View-Adapter), MVVM (Model-View-ViewModel), HMVC (Hierarchical Model-View-Controller), and others. Each of these has very specific properties; the particular format I will be using is probably more MVP than MVC.

For more information about MVC specifics, I suggest Martin Fowler’s excellent article “GUI Architectures” on his website).

What Is MVC?

At a practical level, MVC is a pattern consisting of a number of separate modules of the following types:

• The Model is somewhat misnamed in my opinion, but it’s too late to do anything about that now. Essentially the model is the business rules, the logic, that you want to apply in your application. It may or may not contain the access code to get to the data.
• View is pretty self-explanatory; it is the code required to display the information that we have accessed or the user wants to enter.
• Controller is the code that ties the other two together, acting as the traffic cop that tells the logic flow when to go to the appropriate module.

Generally, you will have multiple model and view modules. That is, it’s quite probable that you will have a number of screens in this function, and each one would be a separate view module. Similarly, you could easily have several models, each one oriented around retrieving or processing a specific type of data. Usually, however, there is only one controller module, although that is a guideline, not a rule. (Although now that I am editing this, I can’t imagine you needing two controller segments. Maybe it should be a rule.)

What is a rule is that whatever you code up, it should fit into one, and only one, of these categories (model, view, or controller). And it should be true to the spirit of ILE: each module should have basically one and only one logical idea behind it.

After that, it is a bit of a judgment call.

For example, some people feel very strongly that you need to separate out your data access logic from the model code. And in some ways that makes sense, particularly if there is much chance that you will change the database or platform that you are on. If you separate the data access, it makes the app much more portable. For us on the IBM i, that is probably not going to happen (unless you switch from DDS to DB2), and so for simplicity I believe in keeping the data access code in with the logic statements in the model. But that’s just me. And most normal people.

Other people get fixated on the relationship between the model and the view.

In theory, the controller should be the intermediary between the model and the view, but the fact that MVC is always shown as a triangle lets some people build connections between the logic and the display.

There is a version of MVC called MVP—Model-View-Presenter—that is specifically designed to not allow communication between the model and the view. Everything has to go through the controller. I sort of prefer this.

There is also MVA—Model-View-Adapter, which to me seems identical to MVP, although I would never suggest that to a partisan of either.

There is also the MVVM—Model-View-ViewModel, which allows the unthinkable to happen, for the model and the view to communicate with each other via slightly different types of view modules.

I hate to be blunt about this, but I really find it very hard to care. I guess I am more in favor of not allowing the logic (model) and the display (view) to talk to each other, but if it happens I am not going to consider my life a failure. I’ve got a lot of other reasons besides that. No, we are going to look at a middle-of-the-road implementation of MVC and get on with our lives.

Why MVC Is Important

OK, MVC breaks things into specific pieces. Big hairy deal. Like the whole world is about to explode, and they changed the cast for the third Fantastic Four movie, and Peter Jackson just won’t stop making crummy movies that rewrite the two greatest books ever written, and you think I care about MVC? Hey, pal, I got real things to worry about.

But the truth is, we should care at least a little about MVC. And I’ll tell you why.

I do not believe in the wholesale rewriting of applications to make them “modern.” Or at least, I don’t believe in rewriting the whole thing in terms of some other language, such as Java. And yet, RPG is incapable of producing those cute little GUI screens that are so in today. What’s a body to do?

What I am in favor of is taking the big ol’ programs (BOPs) that are out there for an application and breaking them down into model, controller, and view modules. Then I would redo the model and controller RPG code using /Free and ILE. And I would then be free to redo the view portion in whatever Web language is the most exciting at the time.

And so, for me, MVC is a requirement for any modernization.

But it goes beyond modernization. MVC is a requirement to get your programs set so that they are maintainable into the future.

I mean, forget modernization. You don’t need to do that to have your RPG programs continue to function just as they are today. And you can add additional functionality to them to make them even more valuable. But doing that to many BOPs is easier said than done, and when you are done, the program will undoubtedly look even worse than it did before. Going to MVC simplifies and cleans up these programs.

Quite simply, MVC is the next iteration in i program structure. It is replacing the more or less single program app structure with the MVC format. That should be the basis of any modernization that you do.

Everybody Loves MVC, but ...

At this point, you may be tempted to go out to the Web, google MVC, and see what you get. I guarantee it will be a ton. MVC is very widely used, extremely well known, and very effective. And yet, most of the articles that you see will probably be some variation of “MVC is great, but this is what’s wrong with it.”

The reason for that is that most of the articles on MVC are written by Web language people. And things on the Web are more complicated than things in the i world. There are a lot of issues and situations that are standard for them, which just don’t come up for us. As a result, there are a lot more things that can “go wrong” with the relatively simple MVC design pattern. Things like inversion of control and dependency injection. Some of the implementations of MVC, like MVVM, tend to be slow and difficult to implement (don’t even get Dave Bush started). And, since MVC is a design pattern, it does not really force you to do anything. So you can use MVC and still write very complex and disjointed programs. Or have a high degree of data coupling. Or intermix functionality, so that view logic is somehow embedded in the model or model logic shows up in the controller.

OK, so MVC isn’t perfect. If you are determined to screw it up, you will. Common sense and basic programming disciplines are still necessary.

But, MVC does provide a framework to allow you to write applications with a couple of very important characteristics.

First, MVC does force you to be modular, and in an RPG world that is still heavily involved with BOPs, that is an important fact.

Second, it makes a pretty strong effort to separate business logic from the view process from the program flow (control) actions. Yes, you can mess that up, but if you are paying even just a little attention, that shouldn’t happen.

Third, it provides the only way to have flexibility to change your view method and maybe even your database, without having to go through a major rewrite.

And those are the things that I want us to focus on as we develop an example of a /Free-based, ILE-using MVC design pattern application: specifically, modularity and separation of function, two of the keys to developing truly modern applications.

What Ya Shoulda Learned

• You should know how to spell MVC.
• And you should know what it stands for: Model (business logic), View (the display of the data), Controller (application flow control).
• The real thing you need to know is how to create an MVC application rather than doing a BOP. And that is what we will look at next.