I think this is why we went from 3-tier to n-tier; because people who broke their applications into a different number of chunks wanted to call each one a tier. I guess it depends on the implementation.

We are probably talking about 4-tier applications here.

UI-tier --> Business-tier --> Data Objects-tier --> Data Store tier

In this scenario the customer form instantiates a COM customerobj from the businessServices.dll. Tier-1 talking to tier-2

CustomerObj instantiates a customerDataObject from DataObjects.dll
Tier 2 talking to tier-3.

CustomerDataObject, being such a well dressed fellow, comes with many hats. He can talk to SQL Server, a VFP DBC or, as Nancy would like, an XML Store. Which hat he wears is determined by a setting in the registry. This is unknown to the customerobj.

At the moment he talks to SQL Server and so it is a simple matter of SELECTING data using a remote view (I like remote views, others might prefer a stored proc, but that's just a different hat). The data is written to properties that are now available to the customerobj to use. The database is configured to handle all RI.

Tomorrow, we switch to XML. Now, the CustomerDataObject must manage RI within itself. This means extra code to create other dataobjects etc. Again, the business object has no notice of this.

In one case you can say the database handles RI, and in the other, it is the data objects. (Are data objects part of the data layer or the business layer?)

I think though, if RI is not in the database, you can only assume that your database does, in fact, have RI. You can't delete records in SQL Server if they break the constraint rules. But you CAN edit an XML or flat file. You can store a record that has a foreign key that doesn't exist as a primary key.

Here's another way of looking at it. Suppose you are a guy (which I find easy to do) and you go out with a girl every night for a month and all you do is kiss and hold hands. Unless you've been with her all the time, you can't say that she hasn't had sex in a month. You can say that you have managed your referential integrity but you don't know that everyone who has contact with her has. Of course, if there was a constraint that she would only have sex with you (let's, for supposition sake, call it a marriage certificate) then you could deal differently with her (Forget the kissing and hand holding!)

I think the data objects are more part of the business tier than the data tier. I say this because they are likely (though not necessarily) to have some business rules implemented within. Of course, you could say the same with the database and triggers, stored procs etc.



>>>If you go to something like XML, then you write data objects that handle RI issues for you.
>>
>>Exactly. :)
>
>But aren't data objects in the data tier?