我想在我的新项目中实现Generic DAO和Generic Service。我在网上看到了很多例子。
在开始之前，我想知道使用这种设计模式的优缺点。
任何人都可以告诉使用这种模式是否明智？
答案 0 :(得分：1)
当多个DAO类想要与数据库通信时（如示例CRUD（创建，读取，更新和删除）），通用DAO设计模式就会出现，如果没有这个设计模式，您最终会编写单独的代码为每个DAO类进行数据库调用（使用会话）这是一项繁琐的工作，因为每次DAO类的新实现都需要编写自己的代码来处理数据库。
以下是使用Generic DAO的一些优点和缺点。
注意：以下详细介绍了我从SO问题Pros and Cons of the use of DAO pattern
的答案中学到的内容<强>赞成
<强> 1 即可。创建实际存储系统的一个很好的抽象层。
<强> 2 即可。提供更加面向对象的持久层视图。
第3 即可。在域类和代码之间提供一个干净的分离 将从数据库执行数据访问。[使用JDBC，ORM [如 hibernate]或JPA]
<强> 4 即可。一旦设置了一般的 CRUD 流程，就可以使用相同的布局 对其他DAO重复。
<强>缺点
<强> 1 即可。如果您手写DAO，那么代码可能会变得乏味和重复，您必须使用代码生成器/模板和ORM。
问：任何人都可以告诉使用此模式是否明智？
A - 在观察上述优缺点后，我在我的应用程序中使用Generic DAO作为抽象层，以CRUD方式与数据库进行通信，实际帮助我减少了大量重复代码以执行相同的操作DAOs.At首先需要时间来习惯它后来使用Generic DAO会让你的生活变得轻松。
答案 1 :(得分：1)
我认为，对DAO和通用DAO有其他意见会更好。关于Pros的一些话（如果你使用ORM我的建议是有效的，Hibernate是一个例子，而不是简单的JDBC）。
- 创建实际存储系统的漂亮抽象层。
这是一个营销废话。在现实生活中，我们在各种RDBMS（Oracle RDBMS - ＆gt; PostgreSQL）之间进行迁移存在问题。不是谈论存储系统类型的更改（例如RDBMS - > NoSQL）。
- 提供更加面向对象的持久层视图。
没有！要做得很好很难。大多数DAO实现都有许多方法，如
getSomething(String x, String y, String z);
getSomethingOther(String x, String z);
可能是，但这种分离的用处被夸大了。
- 在域类和代码之间提供一个干净的分离，它将从数据库执行数据访问。[使用JDBC，ORM [like] hibernate]或JPA]。
- 一旦设置了常规CRUD流程，就可以为其他DAO重复相同的布局。
这是对的。