将神类重构为 manager/dao/do 分层架构答案

【问题标题】：Refactoring God classes into manager/dao/do layered architecture将神类重构为 manager/dao/do 分层架构
【发布时间】：2014-04-09 13:43:52
【问题描述】：

我目前正在从事一个开源项目，该项目需要我重构大量旧代码并使用 hibernate 来访问我的数据库和 spring 将它们结合在一起。现在的代码使用“上帝”对象，其中数据库查询、业务逻辑、数据库行以及所有 getter 和 setter 都实现到单个对象中。

我想做的是将这些对象重构为以下层：

包含业务逻辑的管理层包含对用于其数据库访问 (DAO) 的数据库访问对象的引用
将查询数据库并返回 DatabaseObjects (DO) 的 DAO 层
只有 getter 和 setter 的数据库对象 (DO)，不包含任何逻辑

到目前为止一切顺利，但现在有一个要求，我不希望最终用户使用任何 DO getter 和 setter。所以我让它们受到包保护，并在我的管理层中添加了 getter 和 setter。管理类 getter/setter 将添加事物的业务逻辑方面，然后调用 DO 的 setter/getter。

所以我现在有了这样的东西（所有管理/DAO 类都有接口，但为了简单起见，我省略了这些）：

public class PersonManager{


    @Autowired(required = true)
    protected PersonDAO personDAO;

    public List<PersonDO> findAll(){
        return personDAO.findAll();
    }

    public void setPersonName(PersonDO person, String name)
    {
        ...Business logic authentication checks...
        person.setName(name);
    }
}

同样，这种方法运行良好，但现在每次开发人员想要使用后端时，管理对象都需要与数据库对象一起使用。由于这是一个开源项目，我担心将 DO 方法公开并跳过管理器（并再次将业务逻辑代码添加到 DO）的诱惑可能有点过大。

所以我现在的想法是创建一个附加层，将管理器和 DO 封装到单个对象中，如下所示：

public class Person()
{
    protected PersonManager personManager;
    protected PersonDO personDO;


    public List<Person> findAll(){
         return personManager.findAll();
    }

    public void setPersonName(String name)
    {
         ...Business logic authentication checks...
         person.setName(name);
    }
}

这会将后端封装到曾经存在的旧“上帝对象”中，但好处是完全空心的，只是调用“分层后端 API”。所以其他开源贡献者在后台清理干净的情况下仍然可以使用旧代码。

但是在我的设置中有一个小问题，那就是“findAll()”方法会在我们真正想要 Person 对象时返回一个“PersonDO”对象列表！（这是因为这是休眠返回我的对象的方式）所以我不知道如何最好地解决这个问题。

除了使用管理器之外别无他法？或者我是否错过了将经理和 DO 封装到一个对象中的其他方式。

【问题讨论】：

标签： java spring hibernate design-patterns dao

【解决方案1】：

这种情况下常用的模式是值对象（VO）和服务类的分离。服务类的各个公共方法通常遵循事务脚本模式。有人称这种方法为“贫血对象模型”，但为了更好或更有价值，它似乎非常适合现代测试方法（TDD、模拟等）以及依赖注入和数据库事务管理。

如果您关注此项目，您的 API 将返回简单的 VO，可以安全地在上游使用。数据库事务边界应该在您的各个 API 方法级别，因此从 API 调用返回的 VO 将与数据库断开连接，并且对其值的更改不会将其返回到数据库，除非 VO 被传回 API为此目的明确设计的方法。

【讨论】：