2

我认为我在构建业务模型时花费最多的时间是验证业务实体并确保实体对象及其关系保持良好的完整性。我对一个好的实体/值对象框架的梦想将帮助我创建可重用的实体/值对象，并像在数据库中一样轻松地为关系创建约束和规则，但是因为我觉得这确实是它们属于模型的业务规则，应该是完全独立于数据库。

应该很容易定义 Person 对象的 Name 属性应该是必需的，Email 属性应该是必需的并匹配某个正则表达式，并且这些规则应该易于重用 f.ex。在我的网络应用程序中验证输入。

我在使用 Linq to sql 方面绝对有最丰富的经验，尽管使用它确实很好，但由于不支持值对象和其他对象而受到限制。我的问题是实体框架或 NHibernate 会更适合，还是有其他技术更适合我的需求？

4

2 回答 2

0

去年我读了一本史蒂夫·桑德森（Steve Sanderson）自己写的小书，向我介绍了 DDD 的概念。尽管这本书是关于 ASP.NET MVC 的预览版，但他真正关注的是 MVC 中的“M”作为一个真正的纯领域模型——使用了这本书的近 1/2 的建模方法（我非常喜欢）。他接近的一件事是在聚合根的上下文中使用值对象（显然）。但是，他还展示了如何使用 Linq 来表示实体以及值对象。

关键是，他指出了 Linq 的局限性，即它必须在每个对象上都有一个标识，包括值对象。他承认它打破了纯领域模型方法。但是，这是让它与 Linq-to-SQL 一起工作的唯一方法。

他的解决方法是给你的价值对象一个身份；但是，将该身份设置为内部的，这样它就不会暴露在您的模型之外。这将允许您在存储库中使用 Linq 链接和共享您的对象；虽然不将其暴露给客户端层 - 所以，就好像它们是专门的值对象。

我相信实体框架也有同样的要求。

AC# 示例如下。

public class MyEntity
{
  [Column(IsPrimaryKey = true
    , IsDbGenerated = true
    , AutoSync = AutoSync.OnInsert)]
  public int EntityID { get; set; }

  [Column(CanBeNull = false)]
  public string EntityProperty
  {
    get
    {
      // insert business rules here, if need be
    }
    set;
  }
}

public class MyValueObjectForMyEntity
{
  // make your identity internal
  [Column(IsPrimaryKey = true
    , IsDbGenerated = true
    , AutoSync = AutoSync.OnInsert)]
  internal int ValueObjectID { get; set; }

  // everything else public
  [Column(CanBeNull = false)]
  public string MyProperty { get; set; }
}
于 2009-03-19T18:30:20.957 回答
0

尽管看起来您是在世界的 .Net 方面，但我强烈推荐 Eric Evans 的书“领域驱动设计”。（实际上 UML 比 Java 多，这些想法应该移植。）

这是一本模式书，但他提出了许多设计策略，主张将所有对象规则逻辑（“不变量”）粘贴到一个集中的域中；然后，他继续反复讨论一些普遍理解的模式，并使像你这样的问题看起来更容易处理。好吧，如果不易于处理，至少从长远来看更易于管理。

于 2009-03-31T04:47:32.100 回答