> I think this is where the difference between object modeling, data modeling,
> and mapping the two comes into play. I think most VFP programmers thik of
> things in terms of DATA... Since we are so close to data we see that a
> Customer with Phone numbers and Addresses are in different tables and where
> used to dealing with this in 2.6.

> But, now we are modeling a Business Object, which says nothing about the
> data... and we have a DBA model that data... Then we map the two togther...
> So, when the DBA models the data for the Customer Object we don't care how he
> mapped it table wise...

Yes, that is true. That's why I'm using systems that are totally different in my examples (such as OOP databases). As we have the historical burden of orgnaizing data in tables, it is very hard for us to see those issues. Nevertheless, they are there and valid and need to be considered if one wants to build an app that can be used beyond the boundaries of VFP.

> Thinking from the Object point of view, if I delete a Customer, how the
> underlying persistent data is removed is an implementation issue based on the
> database that is being used.

Exactly.

> Ok... so, if all of the above is really true, I am confused as to the
> Customer / Invoice issue... If I delete a Customer I may or maynot want to
> remove the invoices? So, that is a business rule?

> Ok. Say I DO want to remove all invoices for a customer delete... now I have
> to IMPLEMENT that business rule... would I implement the rule in the Middle
> Tier Customer Object or Invoice object... or would I add a Stored Procedure
> to my Data Tier which removes invoices for a passed customer id... and call
> it from the Customer Deleter Trigger.

You would implement it in the middle tier.

A lot of this also depends on how you model. If you consider the invoices part of a customer (just like his name and address), you could argue that invoices belong to the customer entity. And that would be fine as long as the same entity exists in all tiers. Of course, this takes flexibility out of your design as this assumes certain entities. And the more assumptions you make, the harder it will be to find databases that meet those assumptions (or the more work it will be to create those back ends for that matter).

However, I would not consider invoices part of the customer entity as an invoice is a rather big and complex thing by itself, but that's just my oppinion. This was just one example I used.

> Is that RI? Does it matter? Does it matter where I implement that business
> rule? I would think that if I 'strickly' wanted to maintain Business Rules
> seperate from Data then I would implement this casecade delete in the
> Business Layer...

The term RI is somewhat overused in my oppinion. Reason again is historical. It all used to be in the database container. But that's not true anymore. The scenaio grew a little more complex.

>Are we saying NEVER implement business rules in the Data Tier?

Yes, that'c correct.

Markus