Class design for a many to one relationship

[RSH]

Hi,

I have a situation where I have a class Employee.

Each Employee can have multiple Deductions - I have a deduction class.

I have set the relationship up as a "has-a" relationship.

My question is what is the proper way to setup a situation where each
employee may have multiple deductions? Is it a situation where I simply add
a Deduction collection in the Employee class which stores deductions? ...or
do I have a seperate class that manages the collections so basically I would
have an Employee class, a Deduction Manager class, and a deduction class?

Thank you for any insight you might be able to provide.
Ron

 

[Nicholas Paldino [.NET/C# MVP]]

RSH,

I would just use some sort of collection, or better yet, a dictionary
that is keyed on whatever unique identifier you use for each deduction.
Then, I would expose a property on the deductions class called Deductions
and expose that dictionary.

 

[RSH]

Nicholas,

Thanks for the reply!

So Im understanding that I would use a class Deductions to act as the
collection that sits "between" the deduction and employee?

Thanks!
Ron

RSH,

I would just use some sort of collection, or better yet, a dictionary
that is keyed on whatever unique identifier you use for each deduction.
Then, I would expose a property on the deductions class called Deductions
and expose that dictionary.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi,

I have a situation where I have a class Employee.

Each Employee can have multiple Deductions - I have a deduction class.

I have set the relationship up as a "has-a" relationship.

My question is what is the proper way to setup a situation where each
employee may have multiple deductions? Is it a situation where I simply
add a Deduction collection in the Employee class which stores deductions?
...or do I have a seperate class that manages the collections so
basically I would have an Employee class, a Deduction Manager class, and
a deduction class?

Thank you for any insight you might be able to provide.
Ron

 

[Nicholas Paldino [.NET/C# MVP]]

RSH,

If you want. Unless you have some sort of special code that corresponds
to the collection that the Employee class can't handle, then I would use a
separate class, otherwise, I would just use a List<T> or Dictionary<TKey,
TValue>.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Nicholas,

Thanks for the reply!

So Im understanding that I would use a class Deductions to act as the
collection that sits "between" the deduction and employee?

Thanks!
Ron

RSH,

I would just use some sort of collection, or better yet, a dictionary
that is keyed on whatever unique identifier you use for each deduction.
Then, I would expose a property on the deductions class called Deductions
and expose that dictionary.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi,

I have a situation where I have a class Employee.

Each Employee can have multiple Deductions - I have a deduction class.

I have set the relationship up as a "has-a" relationship.

My question is what is the proper way to setup a situation where each
employee may have multiple deductions? Is it a situation where I simply
add a Deduction collection in the Employee class which stores
deductions? ...or do I have a seperate class that manages the
collections so basically I would have an Employee class, a Deduction
Manager class, and a deduction class?

Thank you for any insight you might be able to provide.
Ron

 

[zacks]

Hi,

I have a situation where I have a class Employee.

Each Employee can have multiple Deductions - I have a deduction class.

I have set the relationship up as a "has-a" relationship.

My question is what is the proper way to setup a situation where each
employee may have multiple deductions? Is it a situation where I simply add
a Deduction collection in the Employee class which stores deductions? ...or
do I have a seperate class that manages the collections so basically I would
have an Employee class, a Deduction Manager class, and a deduction class?

Thank you for any insight you might be able to provide.
Ron

I would design a class for the Deductions (assuming the definition of
a Deduction is more than one field), call it say clsDeduction. Then in
the Employee class, I would make a proeprty Deductions that is a
List<clsDeduction> collection.

 

[sloan]

Hmm. Second time I've posted this:

http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry

Customer has Order(s). Orders have OrderDetail(s).

Code is downloadable, and runs against Northwind database.

 

[Peter Duniho]

So Im understanding that I would use a class Deductions to act as the
collection that sits "between" the deduction and employee?

I believe that Nicholas may have meant to write "expose a property on
the Employee class", rather than "expose a property on the deductions
class".

The advantage of using a Dictionary as he suggests is that if you have
some sort of key associated with each type of deduction, it's easy to
retrieve a specific deduction from an employees collection of deductions
(or to find that it's not present, of course).

But you don't need a new deductions class to take advantage of that, and
based on Nicholas's follow-up post, I'm guessing he didn't really mean
for you to create one, if a Dictionary by itself suffices (and it
probably would).

Pete