DDD中的数据访问层设计

Question

DDD中的数据访问层设计

ormdomain-driven-designpocodata-access-layer

4

对不起，我的英语不够好。

好的，我现在正在考虑DDD方法，听起来很棒，但是...有一个小问题。DDD说，领域模型层与数据访问层（以及所有其他层）完全解耦。因此，当DAL保存某个业务对象时，它只能访问该对象的公共属性。现在问题来了：

通常情况下，我们如何确保一组公共数据足以后期恢复对象?

例子

我们有以下业务规则：

必须为创建的业务对象提供用户和域。
创建后不能更改用户和域。
业务对象具有类似于"user@domain"的电子邮件属性。

这里是描述这些规则的纯POCO：

public class BusinessObject
{
    private string _user;
    private string _domain;

    public BusinessObject(string user, string domain)
    {
        _user = user;
        _domain = domain;
    }

    public string Email
    {
        get { return _user + "@" + _domain; }
    }
}

因此，在某个时刻，数据访问层(DAL)将把这个对象保存到外部存储器(即SQL数据库)中。显然，DAL将"电子邮件"(Email)属性保存到DB中的关联字段。一切都能正常工作，直到我们要求DAL恢复对象的那一刻。DAL该如何做呢？对象至少必须有一个公共的"电子邮件"(Email)字段设置器。就像这样：

public string Email
{
    set
    {
        string[] s = value.Split("@");
        _user = s[0];
        _domain = s[1];
    }
}

实际上，该对象将具有“User”和“Domain”字段的公共getter/setter以及方法GetEmail()。但是，停一下。我不想让我的POCO具备这样的功能！这并没有任何业务规则。这只能为了保存/恢复对象的能力而完成。

我看到另一个选择。作为DAL的一部分的ORM可以被要求存储恢复对象所需的所有私有字段。但是，如果我们想将域模型与DAL分离，这是不可能的。DAL不能依赖于业务对象的某些私有成员。

我唯一能看到的解决办法是拥有一些系统级工具可以为我们创建对象的转储，并且可以随时从此转储中还原对象。当DAL需要从存储中还原对象时，它必须将此转储放入存储中，除了对象的公共属性之外。因此，当DAL执行不需要实例化对象的操作（即大多数link2sql查询）时，可以使用保存在存储中的公共属性。

我是不是做错了？我需要读更多关于一些模式，ORM的内容吗？

- akakey

2个回答

1

public class BusinessObject
{
    private string _user;
    private string _domain;

   public BusinessObject(string email)
   {
      string[] s = value.Split("@");
      _user = s[0];
      _domain = s[1];    
   } 

   public BusinessObject(string user, string domain)
    {
        _user = user;
        _domain = domain;
    }

    public string Email
    {
        get { return _user + "@" + _domain; }
    }
}

一个简单的解决方案是让你的数据访问层调用 new BusinessObject(email)。

- Todd Smith

我认为这是相同的东西。现在我有能力创建我的业务对象提供电子邮件，但我仍然没有适当的业务规则。 - akakey

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Dmitry · Accepted Answer

我觉得您误解了这部分内容：

我还有一种选择。数据访问层中的ORM可以被要求存储恢复对象所需的所有私有字段。但是，如果我们想将领域模型与数据访问层分开，则这是不可能的。数据访问层不能依赖于业务对象的某些私有成员。

领域模型不依赖于数据访问层。事实上，相反，数据访问层依赖于领域模型。ORM对领域对象有深入的了解，包括私有字段。这没有任何问题。实际上，这是在DDD中实现持久性无知的最佳方法。下面是领域类的样子。请注意：

字段可以是私有且只读的
公共构造函数仅由客户端代码使用，而不是数据访问层使用。
不需要属性的getter和setter
业务对象几乎完全不知道持久性问题

数据访问层/ORM唯一需要的是私有的无参构造函数：

public class BusinessObject {
    private readonly string _user;
    private readonly string _domain;
    
    private BusinessObject(){}
 
    public BusinessObject(string user, string domain) {
        _user = user;
        _domain = domain;
    }

    public string Email {
        get { return _user + "@" + _domain; }
    }
}

魔法发生在ORM中。Hibernate可以使用此映射文件从数据库中恢复此对象：

<class name="BusinessObject" table="BusinessObjects">
    ...
    <property name="_user" column="User" />
    <property name="_domain" column="Domain" />
    ...
</class>

持久化无关的领域代码还有一个方面是DDD Repository：

定义：Repository是一种机制，用于封装存储、检索和搜索行为，其模拟了对象集合。

Repository接口属于Domain，并且应尽可能基于Ubiquitous Language。另一方面，Repository实现属于DAL (依赖倒置原则)。