Hey Vic,

>Would I create a controller object for each Order and OrderDetail? Taking this even further, would every object be responsible for its own CRUD operations? Or would it make sense to allow a single controller object to manipulate for both Order and OrderDetail since the relation is pretty obvious? Or another option would be to allow each controller object to controller its own CRUD where it makes sense?
>

Bonnie is right in the sense that Order is a container for OrderDetails; it controls the lifetime of its child objects. The name for this design pattern is Aggregates (http://patternshare.org/default.aspx/Home.DDD.Aggregates). Order is the aggregate root for your object containership hierarchy. So the Order class will have an AddDetail(OrderDetail detail) method and so on. The AddDetail method could just add the detail object to the Details collection but also these methods provide a convenient place to put business rules and enforce invariants.

For query type operations (Get, Add, Update) you create a Repository class(http://patternshare.org/default.aspx/Home.DDD.Repositories) for each aggregate root (this is the "controller" that you were talking about). So the OrderRepository may have GetOrder(int orderId) method that returns a single order. It may also have a GetOrdersForCustomer(int ClientId) that return a collection of Orders. The repository would also have an AddOrder(Order ord) method that persists a new order to the database including saving its orderdetails children, for example. There is no repository class for OrderDetils because you always access details through its order root. Also notice that the repository is strongly typed to your business objects.

If you are using Object Relational mapping then you are done; there is no need to create data access classes. If you are not using Object-Relational mapping then the actual CRUD operations are on DataAccess classes. One data access class per entity. So there would be OrderDA and OrderDetailDA. It is the Repository that references the data access classes and calls the CRUD methods.

The important point is that that the business objects know nothing about the data access CRUD classes. Do not mix business logic with data access logic. There is no Save method on the business objects since they do not know how to persist themselves. The CRUD classes are just an implementation detail for the repositories so you could swap them out with any other type of peristence mechanism or API (DLINQ, nHibernate, EntLib, DataSet, etc.)