像这样实现数据访问对象是一种好的还是自然的方式？

Question

在阅读了Fowler的PoEAA之后，我真的对什么是设计数据访问层的好方法或自然方法感到困惑。我曾经让数据访问对象返回一个简单的java bean，如下所示：

public class Person {
    private long id;
    private String name;
    private Gender gender;

    //... setters and getters
}

数据访问对象类似于

public class PersonDataAccessImpl implements PersonDataAccess {
    public Person getPersonById(long id) throws DataAccessException {
        //... select the database
    }
    public void addPerson(Person person) throws DataAccessException {
        //... insert into the database
    }
    ...
}

但根据PoEAA的说法，数据访问层通常位于各层的底部。让DAO依赖于bean对象(Person)，这不是一个很好的方法吗?这些bean对象将在域层、服务层和表示层中使用。以及如何设计域层，因为在我看来，域对象和简单的java bean之间的区别在于，简单的java bean只缺少域对象中的行为。

Answer 1

显然没有一种真正的方法来构建应用程序，但我自己的想法是...

我同意普通java bean和域对象之间的主要区别在于行为。但我认为你真的应该在你的域对象中有行为，否则你就会冒着anemic domain model的风险。使用域对象设计域模型，而不仅仅是像getter和setter这样的普通对象。如果它是一个域的一部分，那么它确实可能有一些相关的行为。

您的数据访问对象完全可以依赖于域对象，例如Person -事实上，我认为这完全是它们的目的。我认为数据访问是关系数据存储和对象模型之间的映射。您的简短实现片段看起来实际上类似于存储库，它只是域和数据映射层之间的中介者。

有一些争论认为，您应该避免在表示层中使用域对象，而只向客户端公开轻量级数据对象以供查看。(例如，请参阅ASP.NET MVC应用程序中视图模型类的一般概念。)您的服务层实际上将从域对象转换为这些视图对象，并将它们提供给前端客户端。这方面的一个关键论点是，如果某个未知的客户端要使用您的服务，您不希望他们拥有对您的域对象和所有业务逻辑的完全访问权限-您只想向他们提供他们需要知道的内容，以便显示给用户。如果你是你自己的并且是唯一的客户，那么这不是什么大问题。

当然，您并不总是需要一个复杂的域模型。您可能有更像Active Record的东西，其中域对象管理自己的持久性。您还可以查看诸如CQRS之类的内容，在这种情况下，您可以完全绕过域模型，将视图信息从存储的数据视图直接转到定制的视图类。(但是，域模型仍然用于命令端。)

我的建议是:如果它足够复杂，请执行以下操作：

data

• 有一个带有behaviour

• have的对象域模型，它是一个在域模型和数据存储之间进行协调的数据访问层(这将取决于您的域objects)

• have一个服务层，它公开了您的应用程序的必要操作，以便客户端显示和回发