views:

430

answers:

1

Hello All

I'd like to have an 'UnassignedDepartment' object instead of letting employees have a null Department:

public class UnassignedDepartment : Department
{
    public UnassignedDepartment() : base("not yet assigned") {
        Id = -99; <-- just some Id that can be held constant, not be generated..
    }
}

This is accessible by a static convenience field in the Department class:

public class Department : Entity
{
    public static readonly Department UNASSIGNED = new UnassignedDepartment();

    ....    
}

I'm using S#rpArch's framework as the base Entity, with a mix of FNH automapping, overrides & conventions. From a persistence standpoint, it seems logical to keep this with the other Departments with a 'special' Id, but I don't know how to do that properly. Please enlighten me!

Thx, Berryl

+1  A: 

I don't understand what you're trying to accomplish but maybe this will help. Map Department as a private field in Employee and return UnassignedDepartment if it's null.

private Department _department; // map this in FNH

public Department Department
{
    get { return _department ?? _department.UNASSIGNED; }
}
Jamie Ide
Sorry for not being more clear. The object model has all the logic I need and works just fine. It's the persistence (NHibernate/FNH) mapping I'm trying to solve, which just gave me a thought. Instead of thinking of this as an inheritance issue, I think I just need to extend the proper Repository to flatten the object inheritance one that has a Special Case (duh). I'll try that tomorrow and post the results Or ask a different question :-).
Berryl
Paraphrased from Fowler Refactoring, one option for a Electric Utility company to deal with an unknown ResidentialCustomer (maybe they abandoned the house, whatever) is to have the Customer property literally be null. But then you've got to check for null references when you invoke Customer.CalculateBill, so you make an object that is a subclass of Customer to use polymorphism and avoid all the null checking (Null Object). Better yet, make an Occupant subclass that knows the right address and can accumulate the costs when someone takes the foreclosed house and becomes a normal Customer.
Berryl
My question is how to map this in the db using NHibernate. One concept (I think this is where Jamie was going) could be to use NHib to access a pvt field and actually store null in the db while the object model treats null as Occupant, or in my case UnassignedDepartment. But does that mean you lose referential integrity? Plus it would limit you to one Special Case. The only other option I see is to make the db also treat this special, with some constant Id (ie, -1), but then you have issues preventing edits on it.This is the motivation and problem I am looking to solve.
Berryl
Actually, I deal with utility data and it's primarily linked to the premise and the meter. So usage data is only indirectly linked to a current customer.A couple of your ideas make use of "magic numbers", i.e. -99, -1, and this should definitely be avoided.I would let Department be null unless I had a very strong motivation to do otherwise. It would take a compelling argument to make me implement something like your UnassignedDepartment.
Jamie Ide
If you have more than one special case, you could extend Department and map it using table-per-class with a discriminator. You would need a business rule (perhaps a trigger) to ensure that the database only contains one Department record for each special case.
Jamie Ide

related questions