This sounds like the object oriented concept of Model-View-Controller.
Model is the data and as many business rules as possible encapsulated
with the data. E.g. only accept a value of 'A' or 'B' for a table's
field else send a message (or throw an exception). The data edits can be
set up as DB constraints or as part of a data object. The model should
be as smart as possible.
View is the UI itself. The View should be self sufficient. A good
example is a fully loaded subfile. The user can page back and forth and
the program knows nothing about it.
Controller may include business rules that are not in the Model. The
controller's job is to convey messages between the View (user) and the
Model (data repository). It passes data back and forth. The model knows
how to access the DB, not the Controller. The View knows how to interact
with the user, not the Controller. The controller should ask the Model
if it likes the user's data and send the Model's response back to the
View. If really well abstracted, the Controller could work with any UI
-- the assumption being that the UI is an object that knows how to run
itself. E.g. a browser or GUI objects. The controller should be as
stupid as possible.
In your example, the Controller asks the user, via the View, for
retrieval parameters. It sends those to the Model which returns a result
set of data. The Controller feeds the subset to a "load data"
procedure/method which loads the data into a subfile or a Table object
depending on the type of View in use. The View talks to the user. The
controller sends the Add/Chg/Dlt request back to the Model which
responds with a message (success or diagnostic info) that the
Controllers passes back to the View.
From: Booth Martin [mailto:booth@xxxxxxxxxxxx]
Sent: Tuesday, September 08, 2009 12:34
To: Midrange Systems Technical Discussion
Subject: Design question - layered approach