I have been trying to brainstorm this with little success. The practice around here is to have the business object reflect the database table schema, since that follows the business "structure". For example the Parent table would have an ID, FirstName, and LastName column. Therefore the .NET class will have an id (to know how to communincat to the db), firstName, and lastName field.
The problem is, due to relational constraints, we have a Child table that has a forein key constraints to the Parent table. The Child is a collection of the Parent's Children. The point is that the Parent has no knowledge of the Child. So for the Child class we have an id (int) and parent (Parent instead of ParentID) field. However, I want that in the class, the Parent should be able to hold a collection of Children. Which would mean that the Parent referneces the Child (via the collection) and the Child references the Parent (via the Parent field). Technically, this allows for some possible inconsistancies, namely that for a given Child the parent field will be one Parent but that Child will be in a collection of another Parent. I paritally resolved this by putting a Parent parameter in the Child constructor and making the Parent field readonly. But once you have the instantiated Child, the Child can be added to any Parent's collection. I know I can make the parents Child collection a readonly collection and put an addChild method in the parent which will check before it addes it to the collection that the Parent matches, but that means on every add I would have to recreate the readonly children collection, which is a bit expensive.
Can anybody suggest a good design pattern for something like this?