Rarely do M:M relationships exist at the object level.
The ProjectTracker sample covered in the book has a M:M relationship between projects and resources. But in reality, the edit a project use case has projects and "assigned resources", and the edit a resource use case has resources and "assigned projects".
This is one of the best examples where relational modeling and object modeling result in different models 99.999% of the time.
The pain usually comes because people try to use CSLA to be like an ORM, or try to make business domain objects act like entity objects. But that's a mismatch at a deeper level than just code, so it shouldn't be surprising that it causes pain.
Good relational models and good object models just don't look the same. Trying to make objects look like the database ignores the meaning of the word 'mapping' in ORM, and of course causes pain.
I guess more pragmatically (or usefully), you can usually consider a database M:M as two object 1:N relationships.
That's a bit simplistic, but it generally works.
In a data centric world doctors have patients and patients have doctors.
But in a behavioral world, the relationships are more complex. A doctor may have current patients, or future patients or today's patients. A patient may have in-network doctors and out-of-network doctors and preferred doctors.
The object model flows from the use case, while the data model flows from static data relationships.
Or to put it another way, objects represent a contextual and behavioral view of data, while the database doesn't provide context - it is a static construct. So the odds of having multiple types of object over a single table or set of tables is very high, since most data is used in more than one contextual setting (use case).
Copyright (c) Marimer LLC