Re: Business objects, subset of collection

Responding to Frebe...

We have a disconnect. Your model is typical of how one uses CRUD/USER
layered model infrastructures. That sort of processing is not a good
target for OO techniques.

How do we know if an application is CRUD/USER or not? The first
version of the
application might look like CRUD/USER, but what do we do in the next
version
when we realize the this is not the case? Start from scratch again?

The application has some overall problem to solve. Subsequent versions only change aspects of that basic problem. If that problem is essentially conversions between the UI and RDB views, then it is CRUD/USER processing and will likely remain CRUD/USER processing throughout the application's life. If it does, then it is time for a new application because one is solving a different problem.

The developer still needs to provide a mapping, though, between those
Forms and RDB tables and queries. Typically that is done in the business
layer where one mixes classes like [Invoice] and [InvoiceCollection] and
uses relationships to enforce the inherent referential integrity rules.
That works fine for CRUD/USER processing because all the mapping is
essentially 1:1. No harm; no foul.

Isn't views a good tool for providing mappings othan than 1:1?

Depends upon which flavor of views you are talking about.

But mixing paradigms is usually a very bad idea from an OOA/D
perspective once one is outside the realm of CRUD/USER processing.
That's because the data structures needed to optimize the customer's
problem solution are usually not the same as those needed to optimize
data storage or display and the 1:1 mapping breaks down.

The database schema should be optimized for the customer's problem
solution.

Such optimization utterly defeats the entire relational database model, which is designed to provide data storage and access that in independent of the way the data is used. (Apropos of the point below, the RDB model is just one form of the more general relational model.)

Optimizing techniques for non-functial requirements, like
denormalization for
performance, is almost always a bad idea.

I am talking about optimization for solving a particular problem on the application side, not optimization of RDB schemas.

I point all this out because it reflects a major disconnect between
OOA/D and the RAD infrastructures. So far your application sounds like
classic CRUD/USER processing. In that case using the RAD paradigm and
infrastructures will probably save you a ton of keystrokes.

Indeed. One could also argue 80-90% of all business applications seem
to be CRUD/USER according to your definition.

That was true in the '60s and CRUD/USER processing is still a major part of IT. But today the proportion has shrunk substantially, probably down to the 20-30% range.

But that
will necessarily result in different models than I would use as an OOA/D
guy when solving non-CRUD/USER problems.

Yes, because an OO model would be a network model (with pointers
between
object/records), and not a relational model.

We've been here before, yet you persist in making statements like this. The reality is that an OOA/D Class Model is normalized using exactly the same relational rules as an RDB schema. The differences between an OO Class Model and a Data Model lie in the way their relational model is constructed, not in whether they are relational models.


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

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
.

Relevant Pages

  • Re: Business objects, subset of collection
    ... perspective once one is outside the realm of CRUD/USER processing. ... Such optimization utterly defeats the entire relational database model, ... The reality is that an OOA/D Class Model is normalized using exactly the ...
    (comp.object)
  • Re: Business objects, subset of collection
    ... How do we know if an application is CRUD/USER or not? ... That works fine for CRUD/USER processing because all the mapping is ... Optimizing techniques for non-functial requirements, ... OOA/D and the RAD infrastructures. ...
    (comp.object)