2009-05-01 3 views
5

Я хотел бы иметь объект «UnassignedDepartment» вместо того, чтобы позволить сотрудникам иметь отдел нулевой:NHibernate Mapping Null Object/Special Case Pattern

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

Это доступный статическим удобства поля в классе отдела :

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

    ....  
} 

Я использую рамку S # rpArch в качестве базового Entity, с соединением FNH Автоотображения, переопределяет & конвенции. С точки зрения персистирования логично держать это с другими департаментами с «специальным» идентификатором, но я не знаю, как это сделать должным образом. Пожалуйста, просветите меня!

Thx, Berryl

ответ

2

Я не понимаю, что вы пытаетесь достичь, но, возможно, это поможет. Map Department как частное поле в Employee и возвратите UnassignedDepartment, если оно равно null.

private Department _department; // map this in FNH 

public Department Department 
{ 
    get { return _department ?? _department.UNASSIGNED; } 
} 
+0

Извините за неясность. Объектная модель имеет всю логику, в которой я нуждаюсь, и работает отлично. Это настойчивость (NHibernate/FNH), которую я пытаюсь решить, что только что заставило меня подумать. Вместо того, чтобы думать об этом как о проблеме наследования, я думаю, мне просто нужно расширить правильный репозиторий, чтобы сгладить наследование объектов и посмотреть на это как на просто другой Департамент; который имеет специальный случай (duh). Я попробую завтра и опубликую результаты или задаю другой вопрос :-). – Berryl

+0

Перефразируемый от Фаулера Рефакторинг, один из вариантов для компании Electric Utility, чтобы иметь дело с неизвестным ResidentialCustomer (возможно, они покинули дом, что бы то ни было), чтобы свойство Customer буквально было нулевым. Но тогда вы должны проверить наличие нулевых ссылок при вызове Customer.CalculateBill, поэтому вы создаете объект, являющийся подклассом Клиента, для использования полиморфизма и избегайте всей нулевой проверки (Null Object). Еще лучше сделайте подкласс класса «Подсобник», который знает правильный адрес и может накапливать расходы, когда кто-то берет исключенный дом и становится обычным клиентом. – Berryl

+0

Мой вопрос заключается в том, как сопоставить это в db с помощью NHibernate. Одна концепция (я думаю, что это именно то, где Джейми собиралась) могла бы использовать NHib для доступа к полю pvt и фактически хранить нуль в db, в то время как объектная модель обрабатывает значение null в качестве оккупанта или в моем случае UnassignedDepartment. Но означает ли это, что вы теряете ссылочную целостность? Плюс это ограничит вас одним специальным случаем. Единственный другой вариант, который я вижу, заключается в том, чтобы сделать db также обработкой этого специального, с некоторым постоянным Id (т. Е. -1), но тогда у вас есть проблемы, препятствующие редактированию. Это мотивация и проблема, которую я ищу, чтобы решить. – Berryl