Re: Business objects, subset of collection

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 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?

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.
Optimizing techniques for non-functial requirements, like
denormalization for
performance, is almost always a bad idea.

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.

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.

//frebe
.