RE: Design question - layered approach

On Tue, 2009-09-08 at 13:06 -0300, MCKENNA, Tim wrote:

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.

Begging your indulgence, Tim, may I give this hobby horse a trot?

I have a feeling that it is useful to distinguish (at least) two
levels of rules.

The more basic rules clearly should be enforced by (at least) the
database definition itself. For example , an open invoice is
hardly an asset at all if you do not know who is on the hook to
pay it. Referential contraints are wonderful for keeping
nonsense like this out of the database.

"Business rules" could well include rules like "do not ship stuff
to known deadbeats". Now, it seems to me that shipping stuff to
known deadbeats is probably a poor way to make money, but--should
the business owner decide to do this strange thing--there is no
particular difficulty interpreting the resulting rows in the
database.

Where do you make this distinction (if you make it at all)?

Cheers,
Terry.

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.



-----Original Message-----
From: Booth Martin [mailto:booth@xxxxxxxxxxxx]
Sent: Tuesday, September 08, 2009 12:34
To: Midrange Systems Technical Discussion
Subject: Design question - layered approach