Vladimir Ergovic
Originally posted by Vladimir Ergovich:
I would say many to many.
So you can say something like this:
public class Landlord{
private Vector properites;
....
}
public class Props{
private Vector landlords;
....
}
So you will have all relations.
Larman writes "Attributes should not be used to relate conceptual classses in the domain model."
Besides, just like in relational database design, many-to-many relationships should usually be simplified by using a go-between map to make the relationships 1-n on both sides.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
I hope you didn't want to imply that your object model should be driven by database design
Originally posted by Ilja Preuss:
I hope you didn't want to imply that your object model should be driven by database design... ;-)
Originally posted by Ilja Preuss:
That is, when thinking about an object model, I don't really care about "relationships" that much. Instead I do care about responsibilities and collaborations. That is, I don't care about wether a landlord "has a" property - for me the question is: What is the responsibility of a landlord and does it need the collaboration of a property to fullfill its responsibility?
Originally posted by Matts Smith:
I've seen projects with so called top-notch object models fail because they were not taking into account the DB design.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
Interesting - could you elaborate on this? Where did the problems emerge?
Originally posted by Matts Smith:
Basically, when the application persisted the data in the database, since the object model was so far away from DB design the persistence classes where not cohesive and tightly coupled. It led to maintenance nightmares. The architect got fired on that particular project...
Regards,
Pho
Originally posted by Pho Tek:
I read somewhere that you should let your domain model dictate the database model; not the other way round.
Pho
Today's lesson is that you can't wear a jetpack AND a cape. I should have read this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
|