Re: 3 tier architecture: a lot of questions

• Previous message: H. S. Lahman: "Re: Is "AD-HOC polymorphism" actually Polymorphism?"
• In reply to: Gerd Gotthard: "3 tier architecture: a lot of questions"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Sat, 07 Aug 2004 20:44:01 GMT

Responding to Gotthard...

> We plan to redesign our 2 tier financial application towards a more
> versatile 3 tier architecture:
>
> GUI
> |
> Business Objects (BOs)
> |
> RDBMS

Based on you responses to others, I'll assume that the justification
here is that your middle layer actually solves some business problem
rather than just acting as a format conversion pipeline between the RDB
and the GUI. However, given that...

>
> For the persistance of the BOs there are such concepts as Object
> Relational Mapping (ORM), which map objects to relational database
> tables. So far, so good.

I am skeptical. That sort of stuff works fine for CRUD/USER but it
tends to break down when the mapping is no longer 1:1.

I would solve the business problem first. That will determine what the
data needs are. Those needs are the requirements on the interface to
the RDB access layer. Then one solves the problem of RDB access by
figuring out how to convert the <BO> interface requests into RDB queries.

That is, the semantics of the middle layer is Customer and Store while
the semantics of the RDB access is Table and Tuple. The job of the RDB
access layer is to perform that mapping and mess with the relevant
technologies (e.g., SQL). Neither layer really cares about or should
know about the other's view.

>
> The way from GUI to BO is more obscure to me, because there are
> several aspects which i fail to assemble to a reasonable design:
>
> 1. It is necessary that user input is validated immediatly (e.g. the
> "termination date" of a contract can't be before the "start date"). It
> is not preferable to wait until the user wants to save the contract.
> To my understanding validation (check value against rules) is a part
> of the BOs. So if the user leaves the "termination date" text field,
> the GUI has to communicate with the BO to validate the date. Which
> patterns are appropriate?

When in doubt validate as close to the data entry as feasible. The GUI
and the BOs are abstracting the same problem space entities, albeit in
very different ways -- Customer/Store vs. Window/Control). If the
information is resident in GUI objects, then it is quite reasonable to
enforce the business rules there -- subject to some caveats below.

Where things get stickier is when the validation data is not yet in the
GUI. In that case one must either request it from the BO layer or ask
the BO layer to do the validation. At that point a request to the BO is
being made and the BO is providing an answer both ways. Six of one;
half a dozen of the other.

I belong to the School that believes one should only perform checks in
the GUI that are consistent with the GUI level of abstraction. For
example, a range check on a field really doesn't have a lot of business
semantic content. The range values may vary from one field to another
because of the business semantics, but they can be expressed quite
generically for any numeric field.

The acid test I would use is to ask whether the validation data could be
supplied in an external configuration file. (Note one can express some
pretty exotic rules if one uses things like XML strings as configuration
data.) In fact, this is routine for common things like range checks and
the real semantics is externalized by defining the configuration file.
If one can envision a nice generic way to do that, then I would opt to
do the check in the GUI. [The corollary is that if one can envision
that, one will probably design it into the GUI. B-)) (An alternative
to an external configuration file is for the BO layer to provide a
cookie-like validation specification when a new context is introduced.)]

Another thing to remember is that the GUI exists to communicate with the
user. If one has to drag in objects to validate the user data that have
to be hidden (not displayed) because it would disrupt the user context,
then I would be inclined to let the BO handle that stuff because it is
not related to the GUI's primary mission. (I am talking about data
aggregates here, not individual validation values.)

Finally, I would only do checks in the GUI that involved pure data
tests. If the validation rules have to be encapsulated in a behavior
responsibility, then I would leave that level of complexity for the BO.
  IOW, KISS applies.

>
> 2. What about drop-down-lists? If the user has to enter the currency
> of a contract, I would like to present him a list of possible
> currencies by means of a drop-down-list widget. The set of currencies
> may vary, depending on the contract type. To provide this list of
> possible values is again part of the BO, isn't it?

Above I said I was reluctant to drag in data aggregates that wouldn't be
displayed, but these would be. Whatever is fair game for display in the
current GUI context is fair to ask the BO for.

But I think the issue has deeper philosophical significance. A common
mistake in OO development is to view the UI as running the application;
that all activities are driven by the GUI message loop. That is not a
good way to think if one is solving significant business problems.

A better view is that the UI is a peripheral service to the problem
solution (BO layer). That service is simply to communicate with the
user. In this view everything is driven by the needs of the solution.
Even if the user needs to provide data, it is the problem solution that
decides what data is needed (which form to use) and when it is needed.

With that view in mind the answer to your question becomes easy: the BO
is always the source of everything the user sees. When a form is put up
on the tube, it is the BO's responsibility to provide any data that
resides in the form's controls, including pick-list values.

>
> 3. For the calculating the asset of all transactions of a day (and
> there may be a lot of them) I need almost the same BOs like those when
> entering or modifying a contract, except that I do not need any
> information for validating (because at the end of a day, all contracts
> are in a valid state). Do I need to design two (derived) classes:
>
> contract (basic contract information, ideal for massive calculations)
> ^
> |
> contract_val (basic contract + additional validation information)

Without more detailed information I cant say for sure, but I am very
skeptical this is the best way. I would look to delegate the validation
responsibility (i.e., encapsulate it in its own object) and then
parametrically determine whether the validation was required based on
end-of-day context. If it isn't, don't send the message to invoke it.

[One thing to think about if performance isn't a big issue. You might
always do the validation but parameterize what to do if there is an
failure. For single contract entry and error would presumably kick back
to the UI while the end-of-day processing would be a correctness exception.]

>
> 4. In our 2 tier application, which we developed with Borland
> C++Builder (similar to Delphi) we are spoiled by its easy way to
> connect database fields with visual components (=data aware
> components). Updating and validation are performed by "Field" Objects
> which link on one hand to the database fields and on the other hand to
> the visual components. Are there any workframes which provide "BO
> aware components" which accomplish the same functionality?

I don't know anything about the Borland products, so I can't comment
directly. However, I would point out that there was a reason you
decided to go to a 3-tier architecture. Whatever that was is the
trade-off against the convenience of the 2-tier "canned"
infrastructures. IOW, there is no free lunch. B-)

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

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

• Previous message: H. S. Lahman: "Re: Is "AD-HOC polymorphism" actually Polymorphism?"
• In reply to: Gerd Gotthard: "3 tier architecture: a lot of questions"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]