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

发布于 2024-08-16 18:38:04 字数 435 浏览 3 评论 0原文

我正在考虑做这个架构

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

原文

i thinking of doing this architecture

genericdao +interface ---> servicelayer+interface---> view layer

my dao will only have generic methods, my service layers will have real logic for instance

service layer method

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

Do you this this is good architecture

my question is whether suitable to move the "select.." statement from dao into service layer

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

〃安静 2024-08-23 18:38:04

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

我对你的服务代码并不着迷。持久化接口的全部意义在于将 SQL 从客户端中抽象出来，但您却让 SELECT 泄漏到了您的服务层中。在我看来，这是错误的。

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

我假设“generic 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 要么是您的练习，要么必须等到我可以发布源代码。

Your use of interfaces is pretty much the way Spring does it, whether or not you use generic DAOs. It includes the web tier as part of the view.

I'm not crazy about your service code. The whole point of the persistence interface is to abstract SQL away from clients, yet you've let SELECT leak into your service layer. Wrong, in my opinion.

There's little or nothing object-oriented about the way you're doing things.

I'm assuming that "generic dao" means something like this.

I've done it with Spring and Hibernate. The generic DAO interface looked like this:

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);
}

So if I have User and Book model objects, I might have two DAOs like this:

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

The GenericDaoImpl is either an exercise for you or will have to wait until I can post the source code.

回复收藏 0 原文

爱人如己 2024-08-23 18:38:04

你的架构有点不对劲。

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

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

的通用 DAO 示例几乎是标准，我建议实现它的变体。 ..eg UserDaoHibernateImpl 扩展 GenericDao

回复收藏 0 原文