1

我正在考虑做这个架构

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 移动到服务层

4

4 回答 4

3

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

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

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

我假设“通用 dao”的意思是这样的。

我已经用 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 要么是你的练习，要么必须等到我可以发布源代码。

于 2010-01-06T01:58:39.870 回答
3

你的架构有点偏离。

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

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

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

于 2010-01-06T02:45:53.423 回答
2

不是真的，不。“tempMap”在做什么？这似乎有点奇怪。

于 2010-01-06T01:58:18.827 回答
0

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

于 2016-04-23T14:22:31.837 回答