2

我有一个接口，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在其名称的末尾带有。

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

4

2 回答 2

1

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

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

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

更新

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

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

如果你想遵循某种命名约定，你可以简单地用SomethingFacadeand重命名你的类SomethingFacadeImpl。

于 2013-04-18T13:44:02.057 回答
1

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

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

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

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

于 2013-04-18T07:45:37.067 回答