nhibernate - NHibernate中的映射装饰器模式

除了这个问题:

Composition over Inheritance - where do extra properties go?

可接受的答案和类似的答案很好地回答了这个问题。但是，如果销售部门和生产部门想要记录有关疾病和休假的其他信息，该怎么办呢？这可能是一种解决方案:

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.
}

显然，这是类(Class)爆炸的开始，只会越来越糟，因此应避免。

一种可能的解决方案是使用Decorator Pattern(四人制)。这将是理想的，但是在这个假设的示例中，持久性是使用NHibernate的。我到处找了一个如何在NHibernate中映射Decorator模式的示例，但没有发现任何东西。我的实验曾一度利用了子类映射，联接子类映射，并集-子类映射，鉴别符，隐式多态性和多对任意映射的各种组合，但是到目前为止，结果并不令人满意。有人破解了吗？ Employee实体将具有任何类型的缺勤集合，因此多态行为是必需的。

最佳答案

在对这种特定类型的应用程序进行建模时，我会尽量避免根据部门对缺勤进行子分类。相反，我会尝试使缺勤处理系统能够支持任何部门。您可以设计一个模型，如果需要的话，可以在缺少的情况下添加自定义属性。这可以使用通用注释字段或字典来完成。然后，可以根据给定的上下文(例如“销售”和“生产”)来进一步构造此数据。

想到这一点的一种方法是，销售部门的缺席就像生产部门的缺席，因此实体的“类型”不会改变。可能会发生变化的是有关缺勤的特定细节，这反过来又保证了继承方法的组成。

关于nhibernate - NHibernate中的映射装饰器模式，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/6723465/