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

Question

我有一个接口(interface) SomethingDao 和一个实现类 SomethingDaoImpl。该接口(interface)仅包含 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 .

我还看到名称“Service”被用来代替它，在这种情况下，SomethingDao 接口(interface)将被重命名为 SomethingService，并且工蜂类将携带DAO 位于其名称末尾。

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

Answer 1

IMO 该代码是“坏代码”模式，更准确地说是紧密耦合的代码。 8 个助手太多了，而且它显然是一个设计糟糕的对象。我知道这是 java，并且可能没有类似 c# 扩展方法之类的东西，这些方法非常适合帮助程序，所以我认为正确的方法是通过 DI 容器使用依赖注入(inject)。

每个需要 DAO 或服务的对象都会将它们作为抽象依赖项获取，大部分作为构造函数参数。

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

要点是，仅使用与上下文相关的对象，代码会将这些对象作为依赖项。我非常怀疑你可能需要 8 个 helper 来完成任何事情。如果是这样的话，那么该代码的作用就太大了，需要重新设计。