CSLA .NET is designed to support smart business objects that are designed around your business use case (or story, or user scenario - which ever term works for you).
This usually means your objects look more like your UI requirements than like a relational data model. You may be able to force CSLA to work as an ORM, but that's not really what it is intended for.
If you really want dumb objects (DTO or entity objects), and to have them handled by "manager" or service objects, you might be better off using some other framework that is designed around that philosophy.
I talk about M:M relationships in Expert 2008 Business Objects, and provide an example implementation in the ProjectTracker sample app. Modeling M:M in objects means the object model itself is almost never M:M though, because that's a relational concept, not an OO concept...
If I'm in the add an order use case, I'll have OrderEdit and LineItemEdit objects (with a LineItems collection to connect them). Each LineItemEdit object sort of represents a 'product', but really it represents the fact that the user wants to purchase a product.
A ProductEdit object would be used in the edit a product use case, but it is hard to imagine where the user would edit order data as part of the process of editing product data. So it is highly unlikely that ProductEdit would have a collection of orders - unless you have a truly unique business requirement of some sort.
I could see where you might have a read-only collection like OrderList of OrderInfo objects so the user could (perhaps optionally) get a look at the orders for a product while they edit the product - that sort of informational display is relatively common - but in such a case you'd have a ReadOnlyListBase and ReadOnlyBase set of classes to handle that sub-section of the use case.
Copyright (c) Marimer LLC