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。

我还看到了“Service”这个名称，在这种情况下，SomethingDao接口将被重命名为SomethingService，而worker-bee类将带有DAO他们名字的结尾。

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

Answer 1

IMO认为代码是'坏代码'模式，更确切地说是紧耦合代码。 8个帮手很多，而且它是一个设计糟糕的物体。我知道这是java，可能你没有类似c＃扩展方法的东西，理想情况下是帮助器，所以我认为正确的方法是通过DI容器使用依赖注入。

每个需要DAO或服务的对象都会将这些作为抽象依赖项，主要是构造函数参数。

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

关键是，仅使用与上下文相关的对象，代码将把它们作为依赖项。我非常怀疑你可能需要8个助手。如果是这种情况，那么该代码会做很多事情，需要重新设计。

Answer 2

如果您的DAO类中只有11个方法，那么您需要这么多辅助类来实现它们是非常奇怪的。

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

确保为数据库/数据源中的每个实体/表创建一个独特的DAO接口/类。这将有助于您使用更简单的DAO类并减少紧耦合。

<强>更新

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

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

如果您想遵循某种命名惯例，只需在SomethingFacade和SomethingFacadeImpl中重命名您的课程。

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

2 个答案: