实体 Bean 和数据访问对象模式答案

【问题标题】：Entity Bean and Data Access Object Pattern实体 Bean 和数据访问对象模式
【发布时间】：2013-03-25 12:32:26
【问题描述】：

我在理解 DAO 设计模式 Here 时遇到了一些问题。

我的困惑在于两点：

在网站的“问题”部分，提到的entity beans...它们仅用于网络技术吗？我相信我将上述设计模式与纯 java 程序一起使用，其中我使用 DTO 和 DAO 使用 generics 来表示几种类型（联系人、事件、工作、学术）。每个都有自己的超类BASEDAO 的实现，它管理到数据库的所有sql 语句及其连接。

现在，我不确定代表联系人、事件、工作的 DTO 是否会被归类为 ENTITY BEAN。我的 DTO 会属于上述网站所说的业务组件吗？

在网站问题部分的末尾，它谈到了组件和数据源实现之间的紧密耦合*。我不确定这意味着什么。谁能详细说明或向我展示一个带有

【问题讨论】：

标签： java design-patterns javabeans dao dto

【解决方案1】：

现在，实体 Bean 是一个 Java EE 概念，您也可以在没有它们的情况下构建 DAO，而且很多都可以。（例如休眠）

要回答您的第二个问题，当您编写自定义代码来管理数据库连接、查询等时会发生紧密耦合，而无需使用 DAO。如果您使用 DAO 并使用数据源，那么当您更改数据存储和/或源时，您的所有业务逻辑都是安全的，可以通过对配置脚本的最小更改来处理，而不是在没有 DAO 的情况下重新编写新代码.

【讨论】：

你的意思是这样的吗：public class JobDAO extends BaseDAO<JobDTO> {...} BaseDAO 处理数据源交互，而 JobDAO 表示可以说自定义可搜索列定义。我不清楚你的意思是业务逻辑是安全的......

【解决方案2】：

通常每个软件都由数据和对这些数据执行的一些操作组成。在过程编程中，操作被表示为以数据作为输入的过程。这里的问题在于，如果在不同的过程中使用同一组数据，那么每次更改该组以适应新过程时，您都可以轻松地破坏另一个其他地方的程序。那就是紧耦合。另一方面，使用面向对象编程，影响它的数据和操作存在于同一个对象上。这意味着你不需要向方法传递和参数，它实际上知道在对象内的哪里找到它。这样，如果您要更改方法，您将只更改该方法所在的对象中的数据。在任何一种情况下，业务逻辑都是对数据进行的操作。 pradeep 的意思是改变你的数据存储技术，即从 sql 到 mysql，不应该破坏在它上面工作的操作（业务逻辑）。您可以通过创建一个独立于数据存储技术的数据表示来实现这一点，例如 DTO（尽管我更愿意使用隐藏他们正在处理的数据的成熟对象）

【讨论】：