这是 DAO 管理器模式吗？适当的类和接口名称是什么？

Question

我有一个接口SomethingDao 和一个实现类SomethingDaoImpl。该接口仅包含 11 个方法，但每个方法都需要一个或多个复杂的 SQL 查询。

我将实现类分成几个更小的类，我们称它们为Helper1、Helper2、Helper3、...HelperN，因为没有更好的名称。 SomethingDaoImpl 具有每个实例，并将方法调用路由到每个实例。

public class SomethingDaoImpl implements SomethingDao {
    private Helper1 helper1;
    private Helper2 helper2;
    private Helper3 helper3;
    // ...
    private Helper8 helper8;

    public List<X> getX(...) {
        return helper1.getX();
    }

    public List<Y> getY(...) {
        return helper2.getY();
    }


    public List<X> getDetailedX(...) {
        List<X> ds = getX(...); 

        helper6.addTo(ds);
        helper7.addTo(ds);
        helper8.addTo(ds);

        return ds;
    }
}

这种技术有名称吗？一个复杂的 DAO 有几个“工蜂”为它做所有的工作，而它只是管理它们？

仅仅是DAO管理器模式，其中Helper1、Helper2、Helper3是DAO对象吗？我对正确的命名约定感兴趣，所以在这种情况下，我会将SomethingDaoImpl 重命名为SomethingDaoManager，而Helper 将变为HelperDao。

我还看到在它的位置使用了名称“服务”，在这种情况下，SomethingDao 接口将重命名为SomethingService，并且工蜂类将在其名称的末尾带有DAO。

谢谢...我想我只是在寻找与此场景相关的命名约定和设计模式。我希望实现尽可能清晰，并且具有暗示我正在使用的模式的名称会非常有帮助。

Answer 1

IMO 认为代码是“坏代码”模式，更确切地说是紧耦合代码。 8 个帮手很多，这显然是一个设计糟糕的对象。我知道这是 java，可能你没有像 c# 扩展方法这样非常适合助手的东西，所以我认为正确的方法是通过 DI 容器使用依赖注入。

每个需要 DAO 或 Service 的对象都会将它们作为抽象依赖项，主要是作为构造函数参数。

public class MyObject
{
    public MyObject(ISomeService serv,IRepository repo){}
} 

关键是，只使用与上下文相关的对象，代码会将这些对象作为依赖项。我非常怀疑你可能需要 8 个帮手来做任何事情。如果是这种情况，那么该代码的作用就太大了，需要重新设计。

Answer 2

如果你的 DAO 类中只有 11 个方法，这很奇怪，你需要这么多帮助类来实现它们。

问题是，为什么您的 SQL 查询如此复杂？

确保为您的数据库/数据源中的每个实体/表创建一个不同的 DAO 接口/类。 这将帮助您拥有更简单的 DAO 类并减少紧密耦合。

更新

正如您在评论中所写，我认为将您的 SomethingDao 视为复杂逻辑的外观接口更为正确。 （This article 很清楚）。

因此，您可以为每个实体创建不同的 DAO，并在您的 SomethingDaoImpl 中使用这些类，实现外观接口。

如果您想遵循某种命名约定，您可以简单地在 SomethingFacade 和 SomethingFacadeImpl 中重命名您的类。