Картирование шаблона декоратора в NHibernate - PullRequest
Новая
       42

Картирование шаблона декоратора в NHibernate

5 голосов
/ 17 июля 2011

В дополнение к этому вопросу:

Композиция над наследованием - куда идут дополнительные свойства?

Принятый ответ и аналогичные ответы на него неплохо отвечают.Но, если пойти дальше, что делать, если отдел продаж и производственный отдел захотят записать различную информацию об отсутствии по болезни и в отпуске?Это может быть одно решение: 

public class Holiday : Absence
{
    //Extra fields go here.
}

public class Sickness : Absence
{
    //Extra fields go here.
}

public class SalesHoliday : Holiday
{
    //Extra fields go here.
}

public class SalesSickness : Sickness
{
    //Extra fields go here.
}

public class ProductionHoliday : Sickness
{
    //Extra fields go here.
}

public class ProductionSickness : Sickness
{
    //Extra fields go here.
}

ясно, что это начало классового взрыва, который будет только ухудшаться, и поэтому его следует избегать.

Одним из возможных решений будет использование Образец Декоратора (Банда Четырех).Это было бы идеально, но в этом гипотетическом примере, постоянство с NHibernate.Я искал повсюду пример того, как отобразить шаблон Decorator в NHibernate, и ничего не нашел.В моих экспериментах, и в одном пункте, использовались различные комбинации отображений подклассов, отображений объединенных подклассов, отображений объединяющих подклассов, дискриминаторов, неявного полиморфизма и отображений "многие ко всем", но пока без удовлетворительных результатов.Кто-нибудь взломал этот?Сущность Employee должна иметь набор отсутствий любого типа, поэтому требуется полиморфное поведение.

Ответы [ 2 ]

3 голосов
/ 19 июля 2011

При моделировании этого конкретного типа приложения я бы старался избегать подклассов отсутствия по отделам. Вместо этого я попытался бы сделать систему обработки отсутствия способной поддержать любой отдел. Вы можете разработать модель, которая позволяет добавлять пользовательские свойства к отсутствию, если это становится необходимым. Это можно сделать, используя либо общее поле примечаний, либо словарь. Затем эти данные могут быть дополнительно структурированы по заданному контексту, например, Продажи и Производство.

Один из способов думать об этом состоит в том, что отсутствие в отделе продаж очень похоже на отсутствие в производственном отделе, поэтому «тип» организации не меняется. Что может измениться, так это конкретные детали об отсутствии, что, в свою очередь, оправдывает композицию, а не наследование.

0 голосов
/ 01 июля 2013

Я наконец-то ответил на свой вопрос. Подкласс Union - это путь вперед, как в следующем примере с пиццей: 

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
                   namespace="Decorator.Domain.Entities"
                   assembly="Decorator.Domain">
  <class name="IPizza" abstract="true">
    <id name="Id" column="Id" type="guid">
      <generator class="assigned"/>
    </id>
    <many-to-one name="Order" class="Order" column="`OrderId`" cascade="save-update" />

    <union-subclass name="Pizza" table ="`Pizza`" >
      <property name="Size" column="`Size`" />
      <property name="Cheese" />
      <property name="Tomato" />
    </union-subclass>

    <union-subclass name="PepperoniDecorator" table ="`PepperoniDecorator`" >
      <many-to-one name="BasePizza" class="IPizza" column="`BasePizzaId`" cascade="all" />
      <property name="ExtraSpicy" column="`ExtraSpicy`" />
    </union-subclass>

    <union-subclass name="OliveDecorator" table ="`OliveDecorator`" >
      <many-to-one name="BasePizza" class="IPizza" column="`BasePizzaId`" cascade="all" />
      <property name="Colour" column="`Colour`" />
    </union-subclass>
  </class>
</hibernate-mapping>

Я более подробно остановлюсь на этом блоге:

http://lucidcoding.blogspot.co.uk/2013/07/mapping-decorator-pattern-in-nhibernate.html

...