具有 DbC 支持的业务实体/值对象框架

发布于 2024-07-13 22:58:01 字数 392 浏览 8 评论 0原文

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

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

我对 Linq to sql 拥有绝对最丰富的经验,尽管使用起来确实很好,但它由于不支持值对象和其他对象而受到限制。 我的问题是 Entity Framework 还是 NHibernate 更适合,或者还有其他技术更适合我的需求吗?

The thing I think I spend most time on when building my business models is the validation of business entities and making sure the entity objects and their relationships maintains good integrity. My dream for a good entity/value object framework would help me create reusable entities/value objects and easily create constraints and rules for relationships as you would in a db but since I feel this really is business rules they belong in the model and should be totally independent of the database.

It should be easy to define that the Name property of a Person object should be required and that the Email property should be required and match a certain regex and that these rules should be easily reusable f.ex. in validating input in my web app.

I have absolutely most experience with Linq to sql and even though it certainly is nice to work with it has limit by not supporting value objects and others. My question is would Entity framework or NHibernate be more suiting or are there other technologies that fit my needs better?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

掩饰不了的爱 2024-07-20 22:58:01

有一本我去年读过的史蒂夫·桑德森本人写的小书向我介绍了情况关于 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; }
}

There was a small book I read last year by Steve Sanderson himself that briefed me on DDD concepts. Even though the book was on ASP.NET MVC as a preview, he really focused on the "M" in MVC as a true and pure Domain Model - using almost 1/2 the book on modeling approaches (which I very much enjoyed). One thing he approached was using Value Objects in the context of Aggregate Roots (obviously). But, he also showed how to use Linq to represent the entities, as well as the Value Objects.

The point is, he noted the limitation of Linq that it must have an identity on every object, including Value Objects. He acknowledged it broke the pure domain model approach; but, it was the only way to get it to work with Linq-to-SQL.

His work-around was to give your Value Object an Identity; but, make that identity internal so it is not exposed outside of your model. This will allow you to link and share your objects using Linq in your repositories; while not exposing it to the client layers - so, it is as though they are Value Objects exclusively.

The Entity Framework I believe suffers from the same requirement.

A C# example is below.

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; }
}
只有一腔孤勇 2024-07-20 22:58:01

尽管看起来您处于世界的 .Net 一侧,但我强烈推荐 Eric Evans 的书“领域驱动设计”。 (实际上,UML 比 Java 更多,并且这些想法应该移植。)

这是一本模式书,但他提出了许多设计策略,主张将所有对象规则逻辑(“不变量”)坚持到一个集中的域中; 然后他继续讨论一些常见的模式,并使像你这样的问题看起来更容易处理。 好吧,即使不容易处理,至少从长远来看更容易管理。

Even though it appears you're on the .Net side of the world, I'd highly recommend Eric Evans' book "Domain Driven Design". (There's actually more UML than Java, and the ideas should port.)

It's a patterns book, but he proposes a number of design strategies that argue for sticking all of the object rules logic ("invariants") into a centralized domain; he then goes on to riff about a number of commonly-understood patterns and makes issues like yours seem more tractable. Well, if not tractable, at least more manageable in the longer term.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文