在Spring和Hibernate中使用泛型DAO和通用服务模式的利弊是什么？

Question

我想在我的新项目中实现泛型DAO和泛型服务。我在网上看到了很多例子。

在开始之前，我想知道使用这种设计模式的利弊。

有人能说出使用这种模式是否明智吗？

Answer 1

我认为，对DAO和泛型DAO有其他的看法会更好。一些关于Pros的词汇(如果您使用ORM，Hibernate作为示例，而不是普通的JDBC，我的建议是有效的)。

1. 为实际的存储系统创建一个很好的抽象层。

这是营销胡说八道。在现实生活中，各种关系数据库(Oracle，->，PostgreSQL)之间存在迁移问题。没有提到存储系统类型的更改(例如，RDBMS、->、NoSQL )。

1. 提供一个更面向对象的持久化层视图.

不是的！这件事很难做好。大多数DAO实现都有几十种方法，如

getSomething(String x, String y, String z);
getSomethingOther(String x, String z); 

1. 在域类和代码之间提供清晰的分离，这将执行数据库的数据访问。[使用JDBC、ORMlike hibernate或JPA]。

也许是，但这种分离的作用被夸大了。

1. 有了常规CRUD流集之后，可以对其他DAO重复相同的布局。

这是正确的。

Answer 2

当不止一个DAO类想要与数据库通信(例如CRUD(创建、读取、更新和删除))时，泛型DAO设计模式就会出现，如果没有这种设计模式，您将编写单独的代码为每个DAO类编写数据库调用(使用会话)，这通常是一项繁琐的工作，因为在DAO类的每一个新实现中，您都必须编写自己的代码来处理数据库。

下面是一些使用泛型DAO的利弊。

注意:下面给出的细节是我从给出的SO问题Pros and Cons of the use of DAO pattern的答案中学到的。

Pros 1.为实际的存储系统创建一个很好的抽象层。 2。提供一个更面向对象的持久化层视图. 3。在域类和代码之间提供一个清晰的分离，这将执行数据库的数据访问。 4。一旦您有了通用的CRUD流集，就可以对其他DAO重复相同的布局。 Cons 1。如果您手工编写DAO，那么代码就会变得乏味和重复--您必须使用代码生成器/模板和ORM。

Q -谁能分辨出使用这种模式是否明智？

A- -在观察了上述优缺点之后，我在我的应用程序中使用泛型DAO作为抽象层，通过CRUD与数据库进行通信，这实际上帮助我减少了大量重复代码来做其他DAOs.At的事情，首先，需要一些时间来适应它，然后使用泛型DAO将使您的生活更加轻松。