views:

21

answers:

1

I don't know how to phrase the question properly so sorry in advance.

Using FluentNHibernate in particular, how would you go about making your entities for some tables that have are being referenced by a LOT of other tables?

For example an Employee entity. Employees are generally used almost everywhere and it would make sense for some programs to have their Employees contain multiple Roles, multiple Tasks, or multiple benefits. Right now I'm picturing it to be like this:

public class Employee
{
    public virtual Employee()
    {
        Tasks = new List<Task>();
        Roles = new List<Role>();
        Benefits = new List<Benefit>();
    }

    public virtual Id { get; set; }
    public virtual Name { get; set; }

    public virtual IList<Task> Tasks { get; protected set; }
    public virtual IList<Role> Roles { get; protected set; }
    public virtual IList<Benefit> Benefits { get; protected set; }

    public virtual void AddTask(Task task)
    {
        task.Employee = this;
        Tasks.Add(task);
    }
    public virtual void AddBenefit(Benefit benefit)
    {
        benefit.Employee = this;
        Benefits.Add(benefit);
    }
    public virtual void AddBenefit(Benefit benefit)
    {
        benefit.Employee = this;
        Benefits.Add(benefit);
    }
}

public class EmployeeMapper : ClassMap<Employee>
{
    public EmployeeMapper()
    {
        id( x => x.Id );
        Map( x => x.Name );
        HasMany( x => x.Tasks );
        HasMany( x => x.Roles );
        HasMany( x => x.Benefits );
    }
}

Now whiel in this example there's just 3 collections, there's the possibility that it'll grow and grow with every association made to employee. Like in a Human Resources System, it'll be associated with everything from Payroll, Addresses, Taxes, Deductions, etc. Wouldn't it get too overblown if I make a collection for every small reference I call?

Is there a pattern to avoid this scenario of coming or is NHibernate designed so that I have to reference every single object that has a foreign key constraint on my objects?

+1  A: 

The employee does not have to know about every fk reference to itself. Only do that for the ones you actually need to reference through the employee.

in a relationship where both sides are mapped, NHibernate needs you to set both sides before it will save correctly.

That simply means that IF you map both sides, then you need to explicitly set the properties on both sides like

parent.children.Add(child); 
child.parent = parent;
dotjoe