The project I'm working is using n-tier architecture. Our layers are as follows:
- Data Access
- Business Logic
- Business Entities
- Presentation
The Business Logic calls down into the data access layer, and the Presentation layer calls down into the Business Logic layer, and the Business entities are referenced by all of them.
Our business entities essentially match our data model 1-1. For every table, we have a class. Initially when the framework was designed, there was no consideration for managing master-detail or child-parent relationships. So all of the Business logic, data access, and business entities, only referenced a single table in the database. Once we started developing the application it quickly became apparent that not having these relationships in our object model was severely hurting us.
All of your layers (including the database) are all generated from an in-house metadata-database which we use to drive our home-grown code generator.
The question is what is the best way to load or lazy load the relationships in our entities. For instance Let's say we have a person class that has a master-child relationship to an address table. This shows up in the business entity as a collection property of Addresses on the Person object. If we have a one-to-one relationship then this would show up as a single entity property. What is the best approach for filling and saving the relationship objects? Our Business entities have no knowledge of the Business Logic layer, so it can't be done internally when the property get's called.
I'm sure there is some sort of standard patter out there for doing this. Any suggestions?
Also, one caveat is that the DataAcess layer uses reflection to build our entities. The stored procedures return one result selt based on one table, and using reflection we populate our business object by matching the names of the properties with the names of the columns. So doing joins would be difficult.