Many-To-Many Relationships.

Many-To-Many Relationships.

Old forum URL: forums.lhotka.net/forums/t/7588.aspx


bniemyjski posted on Tuesday, September 08, 2009

Hello,

I'm wondering what the best practices for implementing the lazy loading / deletes of many to many relationships in CSLA. I've done some reading in the book and in the forums (here and here) and am coming up short.

Does anyone have some sample code / docs that demonstrates the best way to go about this. Do you guys have an BO for the intermediate table? Where does the look up occur in? The BO that the property exists in or in the intermediate class?

Thanks
-Blake Niemyjski

RockfordLhotka replied on Tuesday, September 08, 2009

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.

bniemyjski replied on Tuesday, September 08, 2009

Hello,

Thanks, I'll take a look at this. I've done some talking / research and a lot of what I'm hearing is that dealing with M:M in CSLA is a pain point. Dealing with it myself has been a pain point too. I'd like to remove this for anyone using our templates. I'm sure everyone has a different use case on how they use CSLA and M:M doesn't come up much if your just dealing with objects that don't deal with a RDBMS... But then again not every RDBMS has a M:M.

Thanks again
-Blake Niemyjski

RockfordLhotka replied on Tuesday, September 08, 2009

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.

RockfordLhotka replied on Tuesday, September 08, 2009

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).

bniemyjski replied on Tuesday, September 08, 2009

Hello,

I couldn't agree more. In this case I need to deal with the intermediate for the 1:N

Thanks again
-Blake Niemyjski

Copyright (c) Marimer LLC