【问题标题】:NHibernate POCO modelling instances creating other instancesNHibernate POCO 建模实例创建其他实例
【发布时间】:2011-12-08 21:08:02
【问题描述】:

这是一个困扰我一段时间的 Nhibernate 问题......

如果我将一个简单的订单输入域建模为:

public class Order: BaseEntity
{
   public virtual Customer Customer {get; set;}

   public Order(Customer customer)
   {
    ...
   }
}

public class Customer: BaseEntity
{
   public virtual string Name {get; set;}

   public virtual Order CreateOrder()
   {
      return new Order(this);
   }
}

虽然上面的代码工作创建了一个 Order 实例,但新创建的实例不会被持久化到数据库中,除非:

  1. BaseEntity 或派生类知道 NHibernate 会话(打破 POCO)
  2. 有一个服务层(或存储库)调用 ISession.Save() 新创建的需要 NHibernate 感知的 Order 对象

所以,这让我相信我的 NHibernate POCO 类本身不应该包含我们的任何业务规则(并且应该只保留属性和构造函数),但是域模型“之上”的服务层应该是逻辑应该存在。据推测,该服务层将通过依赖注入接收其持久性功能。

有人愿意确认/否认我关于业务方法不应该存在于 POCO 模型中的断言吗?

谢谢,

大卫

【问题讨论】:

    标签: nhibernate


    【解决方案1】:

    领域模型中的业务逻辑是首先拥有模型的重点。

    如果拥有订单的客户是持久的,您可以使用 Nhibernate 的级联功能使您的订单自动持久。

    【讨论】:

    • 好的,这当然是那些不断发布 IRepository 类型实现的人的观点。在我的问题域中,我需要确保与数据交互的程序员不能任意将任何实例持久化到数据库中。 IRepository 模式总是使用通用的 Save()、Update() 类型的方法,我不允许开发人员使用这些方法。我开始意识到存储库模式只是我们域的错误模式......不幸的是,大多数 NH 用户似乎都在使用它。知道比较 NHibernate 模式的好网站吗?
    • @David,您能否详细说明您希望对持久实体施加哪些限制?例如,您是否可以简单地将 Save 方法移至 Repository 的每个子类,从而在 CustomerRepository.Save 等中施加任何特定于客户的限制?
    猜你喜欢
    • 2022-08-02
    • 1970-01-01
    • 2012-08-29
    • 2019-01-31
    • 2022-11-21
    • 1970-01-01
    • 1970-01-01
    • 2011-11-02
    • 2020-07-20
    相关资源
    最近更新 更多