A "Rich" Alternative for System i GUI Development
MVC stands for Model-View-Controller. Desktop clients for the System i should be implemented with the MVC design pattern and not use the System i simply as a data base server.
Wikipedia defines MVC as
"an architectural pattern used in software engineering. In complex computer applications that present lots of data to the user, one often wishes to separate data (model) and user interface (view) concerns, so that changes to the user interface do not impact the data handling, and that the data can be reorganized without changing the user interface. The model-view-controller solves this problem by decoupling data access and business logic from data presentation and user interaction....
Model --
The domain-specific representation of the information on which the application operates. The model is another name for the domain layer. Domain logic adds meaning to raw data (e.g., calculating if today is the user's birthday, or the totals, taxes and shipping charges for shopping cart items).
View --
Renders the model into a form suitable for interaction, typically a user interface element.
Controller --
Processes and responds to events, typically user actions, and may invoke changes on the model. "
The Model runs on the System i, it is the business logic and data access of the applications. The Model, business logic, is easily kept separate from the presentation (view and controller).
The desktop client is the View-Controller. It displays the data and interacts with the user.
A View is not easily separated from the Controller. Consider two common views, a web browser and a 5250 display. The same Controller can't operate on both Views. The View part is defined by the physical and logical display. The Controller has to interact with the View. The Controller and the View need to "know" about one another. But both pairs of View-Controllers could work with the same Model.
Typically each View has its own Controller. The Controllers for separate Views may share logic and components but they are differentiated by the requirements of the physical view that they control, process events of and respond to.
Sometimes the View and Controller must be implemented separately. That is the case with a web browser. The browser is the view. The Controller can be a CGI program or web services on the server which generates the HTML for the browser and responds to the POST and GET from the browser.
In other cases, such as a 5250 display program, it makes sense to implement the view and controller together. We will combine the view and controller with the Eclipse RCP client.
It is easier to get and manipulate the data within the Eclipse RCP client using SQL or record level access of the Java toolbox. It is also easier to write a 5250 program which does its own data base IO and handles its own data base logic. Think carefully before taking the easy way.
Posted by Bill Blalock at February 28, 2007 8:20 PM

| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 |
We welcome your comments and opinions and encourage lively debate on the issues. However, Penton Media reserves the right to delete or move any content that it may determine, in its sole discretion, violates or may violate its Terms of Use or is otherwise unacceptable. For more information, see Penton Media's Terms of Use.