通用 dao 架构讨论-最佳实践答案

【问题标题】：generic dao architecture discuss-best prastice通用 dao 架构讨论-最佳实践
【发布时间】：2011-01-01 21:40:04
【问题描述】：

我正在考虑做这个架构

genericdao +interface ---> servicelayer+interface---> 视图层

我的 dao 将只有通用方法，例如我的服务层将有真正的逻辑

服务层方法

string executeThis= "select c from com.abc.test.User where username =:username";
Map tempMap = new HashMap();
tempMap.put("username","abc");
return callDaoInferface.executeGenericList(executeThis,tempMap);   //get from DI

你这是好架构吗

我的问题是是否适合将“select..”语句从 dao 移动到服务层

【问题讨论】：

标签： java spring dao genericdao

【解决方案1】：

无论您是否使用通用 DAO，您对接口的使用几乎都与 Spring 一样。它包括作为视图一部分的 Web 层。

我不喜欢你的服务代码。持久性接口的全部意义在于将 SQL 从客户端抽象出来，但您已经让 SELECT 泄漏到您的服务层。错了，在我看来。

您做事的方式很少或根本没有面向对象。

我假设“通用 dao”的意思类似于 this。

我已经用 Spring 和 Hibernate 完成了它。通用 DAO 接口如下所示：

package persistence;

import java.io.Serializable;
import java.util.List;

public interface GenericDao<T, K extends Serializable>
{
    List<T> find();
    T find(K id);
    List<T> find(T example);

    K save(T instance);
    void update(T instance);
    void delete(T instance);
}

所以如果我有 User 和 Book 模型对象，我可能会有两个这样的 DAO：

GenericDao<User, Long> userDao = new GenericDaoImpl<User, Long>(User.class);
GenericDao<Book, String> bookDao = new GenericDaoImpl<Book, String>(Book.class);

GenericDaoImpl 要么是你的练习，要么必须等到我可以发布源代码。

【讨论】：

我的问题是这是否是好的架构。我知道春天可以做到。我的问题是是否适合将“select..”语句从 dao 移动到服务层
是的，你的接口是正确的——这就是 Spring 的架构成语。你的实现是错误的。 SELECT 语句属于持久性。
是的。我非常同意你为什么我要求确认。如果我在 dao 中有一个类似 public List search(String sqlStatement, Map keyValue){} 的方法，我将不得不在 dao 中创建另一个方法，使用“select.. statement”来调用它。我的服务层将调用后一种方法。你觉得呢？
不，错了。我不认为你的方式抽象任何东西，所以我认为这是错误的。你应该放弃这个想法。没有您想要的封装方式。
服务层应该不知道 DAO 如何获取其数据。这意味着 DAO 接口不应该有任何方法参数，例如“sqlStatement”。如果您有一个从消息队列、XML 文件、平面文件等中获取数据的 DAO，该怎么办？

【解决方案2】：

您的架构有点偏离。

您想要一个 dao 接口来抽象简洁的数据库交互，或者换句话说，您可以使用各种实现来实现数据访问契约，例如 JPA、Hibernate、Oracle、JDBC 等。您的查询应该与实现一起存在，你应该查看命名查询，我知道它存在于 Hibernate 和 JPA 中。查询可能会根据实现而有所不同，例如特定于数据库的细微差别（如 MySQL 的“限制”）或 HQL（Hibernate 查询语言）与 SQL。

在我看来，在大多数情况下（比如这个）服务层只是开销。您可能需要一个类似用户授权的服务，您的服务层可能会执行一些业务逻辑来正确构建查找。例如，您可能需要加密/解密密码，或验证用户名不存在、满足最低密码要求等。

Duffy 的通用 DAO 示例几乎是标准的，我建议实现它的变体......例如UserDaoHibernateImpl extends GenericDao<User, Long>

【讨论】：

意思是，如果我有 book 和 user ，car 实体，我必须 BookDaoHibernateImpl extends GenericDao; UserDaoHibernateImpl 扩展 GenericDao; CarDaoHibernateImpl 扩展了 GenericDao;
没有。你会有 GenericDao。如果我在 Spring 中这样做，我必须为每个模型对象创建 bean，但我仍然只有一个 GenericDaoImpl。看不到“延伸”。

【解决方案3】：

不是真的，不。 “tempMap”在做什么？好像有点奇怪。

【讨论】：

tempMap 是将传递给 Query.setParameter(..,..) 的 Map
是的 ... :) 好吧，我的意思是它不是作为实体或实体集合输入的。这是我的首选方式（事实上，我只使用 OR/Mapper：LLBLGen [for .NET]）。我敢肯定，Java 有著名的 OR/Mappers 可以为您执行此操作。我建议你使用它们。
以上都不是。 Java 的 ORM 可以是 Hibernate、TopLink 等。

【解决方案4】：

现在（2016 年）您应该考虑使用 Spring Data JPA，而不是构建自己的通用 DAO。

【讨论】：