基于反射的基本通用 DAO答案

【问题标题】：Basic Generic DAO based on Reflection基于反射的基本通用 DAO
【发布时间】：2014-10-31 19:47:52
【问题描述】：

嗯，我的项目中有一些问题困扰着我。我有很多很多休眠实体类，每个类都有自己的 DAO（继承自 GenericDAO）。它们中的大多数没有特定的功能，只是一个继承 GenericDAO 的空类。

因为我认为那些是不必要的类，所以我决定使用反射来摆脱它们。经过一些编码后，我对除 GenericDAO 之外没有特定方法的所有类的调用遵循以下设计：

DAO.forClass(MyClass.class, MyClassPK.class).genericDAOMethod();

它就像一个魅力。我现在摆脱了空的 DAO。但是通过互联网搜索后，我发现像我这样的解决方案很少甚至没有，所以问题是：

这种方法在很大程度上是错误的还是坏的？为什么没有人考虑做这样的事情？

【问题讨论】：

你能说明这是如何使用反射的吗？我认为，仅仅引用一个类并不足以称之为反射。我认为你可以在调用端使用 GenericDao ，并在你的依赖注入系统中生成这些 daos（假设你有一个）。
我的 GenericDAO 使用 Hibernate，所以我只需要通过 MyClass 和 MyClassPK 实例化一个新的 GenericDAO。我不在这种 DAO 中使用 CDI。换句话说，GenericDAO 类声明是这样的：public class GenericDAO.

【解决方案1】：

反思几乎从未被视为问题的答案。它很难阅读，因为很多人不知道它是什么，而在你身后修改你的代码的人也不容易理解它。使用 Code Complete 书中的术语并不是“自我记录”。

反射很强大，因为您刚刚发现这样做是为了实现 DAO。但你应该厌倦它。我们在我的办公室使用的一个术语是“代码臭味”，这是可能用于特定目的的代码，但除非绝对需要，否则不应在任何地方使用。确保正确记录，以便真正支持你的人知道它到底是什么。

我喜欢用它在 Spring 中编写 jUnit 测试，以使用反射比较来自两个不同数据库的两个对象。但这是一个测试，实际上并不在生产代码中。

希望这会有所帮助，并且是您正在寻找的东西！

【讨论】：

并不是说你会有两种不同的方法来处理有自己的方法和没有方法的类。
感谢您的回答！正如我所说，这个类只是为了继承而解决了实现空 DAO 的问题。在所有其他情况下，我的设计都是垃圾。我已将其记录在课堂上...无论如何，您对解决反射问题的看法很好...我会选择其他观点并尝试通过良好的文档来减少它们。
@Dmytro 它是相同的对象类型，数据库中本质上具有相同的表，因此您使用反射来比较表中的信息。它完全相同的信息，相同数量的字段和所有内容。因此，反射在这里很有用。
@Dmytro，就我而言，这个类很有用，我有大量的“空 DAO”和与业务相关的 DAO。
@Dalton 看看代码有几个方面。一种是纯编程。另一个是开发。从编程的角度来看，没问题。但考虑到开发例如未来的变化、其他开发人员的参与等，这是不行的。希望这能说明我的观点。