Evan, John, and others,

>>Sticking with with the classic 3-tier model is what was causing me problems because it was an artifical constraint. Going to n-tier and putting RI into data services makes more sense.

Would it be accurate to summarize this way for 3-tier:

Business Rules and RI rules could be defined in a 3-tier logical model as being in the business logic and data services layers, respectively. But when converting the logical model to a 3-tier physical model, the data services may end up split between different phyical boxes.

For example, you might have the data store and stored procedures portion on the SQL Server box, and the data services that call those SP's on the same box or even in the same dll's as the business logic.

The same principle applies to User Interface services, which MUST be split when running a Web browser UI. The portion of UI services that processes a request and builds the HTML interface runs on the Web Server, while that actual UI runs on the client browser machine. Yet BOTH are defined in 3-tier as UI services.

n-tier certainly helps there also, by allowing UI services for client, and Presentation services for the potion running on the Web server. So unless we're preparing for testing on 3-tier design :-), we may have less brain strain to define things in more layers.