问题标签 [genericdao]

我正在考虑做这个架构

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

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

服务层法

你这是好架构吗

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

我正在尝试在 java 中开发通用 DAO。我尝试了以下方法。这是实现通用 DAO 的好方法吗？我不想使用休眠。我试图使其尽可能通用，这样我就不必一遍又一遍地重复相同的代码。

我现在有：

我读了这篇文章：

http://www.ibm.com/developerworks/java/library/j-genericdao.html

几次，相信我明白它在说什么。但是，它已经 4 岁了，我有一个符合 JPA 的 Java 应用程序要处理。另外，我看到 Spring 中有一个 JPATemplate 有一些很好的功能，但是 Spring 文档说它已经被弃用了！

任何人都可以指出一个可靠的、现代的、符合 JPA 的、基于 Spring 的 GenericDAOImpl 的工作示例，它代理一个接口以提供通用的查找器执行？

我正在使用带有 sqlalchemy 的塔。我有几个模型，发现自己一次又一次地写这样的代码：

由于模型都是扩展类Base，有没有办法定义一个通用的get_by_id()方法？

所以我可以将它用作：

我知道这经常被问到，但我找不到可行的解决方案：

这是我的 AbstractDAO ：

这是我的 JPA 的实现：

这是一个实体的道：

这是它的实现：

整个架构很简单：

接口AbstractDao定义了简单的 CRUD 方法。

接口PersonDao扩展了 AbstractDAO，没有任何附加方法。

类AbstractDaoJpaImpl定义了 JPA 的 AbstractDao 实现

类PersonDaoImpl扩展了 AbstractDaoJpaImpl 并实现了 PersonDao AND OtherInterface ，它添加了附加方法（） ...

如果， PersonDaoImpl 只实现 PersonDao ，没有实现 OtherInterface.additionalMethods() ，一切正常。

我可以用

在我春天的 XML 文件中。

但是， PersonDaoImpl 实现 OtherInterface(s) ，在测试/运行时，我必须将 DAO 从 PersonDao 转换为 PersonDaoImpl 或 OtherInterfaces，例如：

问题发生时(PersonDaoImpl) dao，抛出“Proxy cannot be cast to PersonDaoImpl”异常：

google的时候经常会问到这个，大家建议proxy-target-class="true"加到<tx:annotation-driven>：

这将使用 CGLIB 而不是 JDK 的动态代理。

但是在初始化 Spring 时它会引发另一个异常：

在 AbstractDaoJpaImpl 的构造函数中：

每个问题都停在这里，我现在找不到任何可行的解决方案。

谁能给我一个可行的解决方案？非常感谢 ！

环境：Spring-3.0.4，javaee-api-6.0，javax.inject，cglib-2.2，hibernate-jpa-2.0-api-1.0.0，

根据我之前的问题，DAO 和服务层（JPA/Hibernate + Spring），我决定在使用 JPA/Hibernate、Spring 和 Wicket 的应用程序中只使用一个 DAO 作为我的数据层（至少在开始时）。提出了使用通用 CRUD 方法，但我不太确定如何使用 JPA 来实现它。你能给我一个例子或分享一个关于这个的链接吗？

我有个问题。我有一个父 DAO：

从中扩展了另一个子 DAO。当我想对子 DAO 中的子实体进行一些操作时，我必须从父类获取 EntityManager 对象或将 entityManager 对象声明更改为受保护，这是糟糕的 OOP 设计。还有另一种方法可以做到这一点吗？因为当我有 100 个 DAO 孩子时，我必须为每个新孩子从父 DAO 获取 entityManager。

我刚刚来自我小小的 JavaSE/Guice 世界，目前正在发现“由容器携带”-EE6 的路径。在 Glassfish3.1 遇到一些问题后，我刚刚切换到 JBoss，现在面临一个不应该出现的问题。

作为基础设施辅助类，我正在尝试为任何类型的实体创建通用存储库/DAO。以一种非常简单的方式，这可能看起来像这样。

现在可能有一个 bean 不需要依赖于实体的查询功能，而只需要某种实体类型的存储库，例如（可能是一个测试用例）：

不幸的是，Weld 似乎不喜欢这种通用注入。在部署时，我收到以下错误：

我是否遗漏了什么或者他们只是忘记了实现通用注入？据我了解通用的东西，无论如何它都会在编译后被删除——即使到目前为止这在 guice3 中工作得很好。

亲切的问候，

avi

编辑：发现garvin king的评论说这种行为在规范中，但没有在焊接中实现，（状态是在 2009 年 6 月）

我正在尝试编写简单的 DAO，它将根据存储在 String 字段中的类型创建实体对象。如何返回动态更改的类型？UserDAO 类的方法 findById() 应该返回 User 类对象。ProductDAO 的相同方法应该返回 Product。我不想在每个扩展 DAO 的类中实现 findById，它应该自动完成。

示例代码：

我有一个 DAO 基础设施，如下所示：

StoreDao、CouponDao、PersonDao。

所有这些都从具有大部分功能（使用 Java 泛型）的GenericDao扩展而来。在这里解释一下 - [http://www.ibm.com/developerworks/java/library/j-genericdao/index.html][1]

当在 StoreDao 上调用 getAll() 时，实际调用的是 GenericDao 的 getAll()，它将某些默认 where 子句（如 active=true, expires>now() 附加到要执行的现有 HQL 查询中。

我们有一堆在 setup() 中创建数据的 Dao 测试，还有一堆断言响应的测试。不完全是单元测试，因为数据库没有被模拟，但我猜可以称为集成测试。

我的一个队友创建了一个测试基础设施来测试生成的 sql 查询是否准确。他这样做的方式如下：

有一个自定义的 Hibernate 拦截器，它拦截 onPrepareStatement()，使用 Hibernate 的 ASTParser 创建即将执行的 Query 的 XML 结构，然后使用 XPaths 来验证查询，例如，查看 where 子句中是否存在某些字段，连接是正确的等。

我们这样做是为了单独测试 Generic Dao。为此，我们必须创建 GenericDomain、GenericChildDomain、GenericDomain.hbm.xml 以及支持这些的表。

问题：

这值得吗？除非我们已经为我们已经拥有的所有单元测试完全模拟了数据库，否则我认为我们没有理由创建这个基础设施。

我们怎么能不使用我们已有的基础设施来测试 HQL。如果要确保将 active=true 附加到查询中，只需确保 DAO 不会返回 active=false 的数据。

最后，我们在这里所做的非常依赖于休眠，如果我们决定用 IBatis/JPA-EclipseLink/NoSQL 替换我们的 DAO，它们大部分都会被丢弃。

最后，我们为什么要发明这样的东西。这不是一个相当普遍的问题吗？不是有人已经建立了解决方案吗？