Re: Modeling

Responding to Kr4ster.news...

Perhaps I'm approaching the solution from the wrong direction.  I'm
writing a basic work order management system (basically as a run-up to
a much larger system).  I'm working with an existing database schema
(used in a legacy app), so I'm starting from there and building up.
The approach I'm using in my design is in building the Data/Services
tier then adding an interface tier -- as I want to provide a web
interface as well as build a remote client.

A work order management system is probably well beyond the scope of CRUD/USER. So I would strongly advise abstracting that problem space in an OO fashion independently of the database.

In the application you can provide a subsystem that provides persistence access by talking to the RDB. That subsystem would have to understand the RDB paradigm with objects like Schema, Table, Tuple, Query, and what have you. But that semantics would be encapsulated within that subsystem.

OTOH, the problem solution solves the problem in its own fashion with a view of the problem space semantics that is tailored to the problem in hand. When the problem solution needs to access persisted data, it talks to the interface on the persistence access subsystem. So that interface is designed around the problem solution's needs. It is then up to the persistence access subsystem to convert that view to the RDB view. [My blog has some categories that provide more details about application partitioning and persistence mapping that may be of interest.]


It seems to me, though, that this would be a somewhat common problem
(hierarchies, ie. Building(1)--(n)Floors(1)--(n)Rooms;
State(1)--(n)County(1)--(n)City;
Division(1)--(n)Departments(1)--(n)Business Units).  The solution in
which the whole hierarchy is stored seems to be rather cumbersome
(across tiers) as opposed to the solution that provides single classes
with an intrinsic hierarchical nature.

In the problem solution those hierarchies are likely to appear as simple associations, something like:

           1     R1       *         1     R2       *
[Building] ---------------- [Floor] ---------------- [Room]

The R1 and R2 relationships are instantiated when the instances are created by updating collection classes. Typically the application will only instantiate those objects that are of interest to the the problem in hand. So conceivably one might have:

           1     R1       1         1     R2       *
[Building] ---------------- [Floor] ---------------- [Room]

in the problem solution because only one Floor is needed at a time. Similarly the number of Rooms that are relevant might be less than the total that exist on the Floor. From that perspective the other floors and rooms do not even exist.

The job of the DB access subsystem if to convert the problem solution request, "I need the even numbered rooms on floor 13," into the appropriate SQL query (or whatever) that will extract just that floor and set of rooms. It then hands just that data back to the problem solution where a factory object knows how to instantiated the objects and relationship collections. To do that all one needs is a shared view of common identity.

[Note an added bonus. Suppose one knows the solution will eventually need the floors above and below and that DB access can be more efficient if one accesses all three floors at once. Now persistence access subsystem essentially provides a read-ahead cache but it doles out floors one-at-a-time on an as-need basis to the problem solution. That optimization for the RDB access is of no interest to the problem solution so it is encapsulated in the DB access subsystem.]

Note that the layered models (Presentation - Business - Data) used for CRUD/USER applications do exactly this sort of thing (read: subsystem <=> layer). That allows infrastructures that hide a lot of the processing (e.g., serializing inherently asynchronous data accesses). That works fine for RAD IDEs that cater to CRUD/USER processing because the mapping of UI objects to RDB tuples is usually 1:1. But for more complex applications the mapping, as in the example above, may not be 1:1.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.