Best way to implement classes that are related as one-to-many

  • Thread starter Thread starter BobRoyAce
  • Start date Start date
B

BobRoyAce

Let's say that you have two entities: Franchises and Franchise Owners.
Since a Franchise can have multiple Franchise Owners associated with
it, and a Franchise Owner could be associated with more than one
Franchise, I created three tables: Franchises, FranchiseOwners, and
FranchiseFranchiseOwners. One of the fields in the
FranchiseFranchiseOwners table tells the PercentageOwnership between
the FranchiseOwner and the Franchise.

OK, so I created two classes: Franchise and FranchiseOwner. The
Franchise class has a property, called FranchiseOwners, which is a
List(Of FranchiseOwner). What I am wondering about now, however, is
how to go about implementing a many-to-many relationship with my
classes. Should I, for example, add FranchiseID and
PercentageOwnership properties to my FranchiseOwner class and then
populate the latter based on the value of the former? Should I create
a third, FranchiseFranchiseOwner class?
 
BobRoyAce said:
Let's say that you have two entities: Franchises and Franchise Owners.
Since a Franchise can have multiple Franchise Owners associated with
it, and a Franchise Owner could be associated with more than one
Franchise, I created three tables: Franchises, FranchiseOwners, and
FranchiseFranchiseOwners. One of the fields in the
FranchiseFranchiseOwners table tells the PercentageOwnership between
the FranchiseOwner and the Franchise.

OK, so I created two classes: Franchise and FranchiseOwner. The
Franchise class has a property, called FranchiseOwners, which is a
List(Of FranchiseOwner). What I am wondering about now, however, is
how to go about implementing a many-to-many relationship with my
classes. Should I, for example, add FranchiseID and
PercentageOwnership properties to my FranchiseOwner class and then
populate the latter based on the value of the former? Should I create
a third, FranchiseFranchiseOwner class?
Click to expand...


One possible way to implement the relationship you describe is through
aggregation. A field in the Franchise class would be a collection of
FranchiseOwner objects representing the owners of the franchise. You could
also do the same in the FranchiseOwner class (a collection of Franchise
objects as a field).
 
One possible way to implement the relationship you describe is through
aggregation. A field in the Franchise class would be a collection of
FranchiseOwner objects representing the owners of the franchise.
Click to expand...

As stated in original post, I am doing just that for the Franchise
class. The question is should I add the PercentageOwnership property
to the FranchiseOwner class and just pull it from the other table
based on the FranchiseID associated with the containing Franchise? To
do this, though, the FranchiseOwner class would have to be aware of
either the Franchise it's associated with, or, at least, the
FranchiseID associated with the Franchise it's associated with. This
seems a little messy, and I'm wondering if there's some "pattern" out
there for how to implement a many-to-many class relationship.

One problem is that I may want to allow the user to edit a
FranchiseOwner without regard to any Franshises they own. In this
case, I wouldn't be able to populate the PercantageOwnership property
of course, and I don't really even care about it. There could be other
such fields as well that I wouldn't care about (from
FranchiseFranchiseOwners). I suppose I could just ignore these fields
if the FranchiseOwner object is not associated with a Franchise, and
do certain processing conditionally based on whether or not it is.

Is there a "clean" way to implement something like this?
 
Your FranchiseFranchiseOwners pivot object seems the right solution to me.
Put the PercentageOwned property there.

I'd call it something other than FranchiseFranchiseOwners if I were you
though - that name is confusing.
 
Back
Top