问题标签 [dao]

Spring 框架在事务处理方面走了多远？我阅读“Spring In Action”一书及其示例建议您创建不用担心会话和事务管理的 DAO 方法，只需在 XML 中设置会话工厂和事务模板，然后将它们连接到您的 DAO。另一方面，SpringSource.org 的文档表明需要大量的 XML 和/或注释来实现这一点。

这里的真相是什么，我可以按照以下方式编写代码的最简单方法是什么

让它只是

将我在我的方法中拥有的样板事务代码的数量减少到最低限度？

所以我已经完成了这个通用的 DAO 事情，从表面上看，它似乎没问题。它基本上是仿照 Hibernate 家伙的 CaveatEmptor 示例应用程序。

最重要的是，我有一个业务层……应用程序的核心。它完全不知道任何特定的 DAO 实现。

到目前为止，一切似乎都很好，直到我开始考虑交易。如果将事务留给客户端来实现，那么我究竟如何保持我在各层之间进行的良好分离？也就是说，我目前正在使用 Hibernate，我不太想将特定于 Hibernate 的事务添加到我的业务层代码中。

我可以使用开始、提交和回滚方法创建一个简单的事务接口，并将实现传递给我的业务层......但是......我不确定......

所以这是一个挑战：你能为我推荐一种不使用 Spring（或 EJB，或任何其他附加框架）这个词的方法吗？

我是否必须在每个函数中打开和关闭会话和事务（制作对象、删除对象、findbyID）

你能给我一个 findall 的 DAO 实现吗（延迟初始化）。

任何人都可以建议 Web 应用程序的 DAO 实现吗？

如果我为基本操作（例如findByID(), findALL(), createObject(),deleteObject()等）创建事务会出现什么问题？

请建议一个支持惰性操作的 DAO 实现。

有问题的场景与备受诟病的Microsoft Jet 数据库引擎有关。断言是数据访问对象(DAO) 数据访问技术是 Jet 的“原生”，这意味着通过 DAO 模型创建对象优于通过在Microsoft Access中执行的 SQL 代码执行相同操作用户界面。

此外，有人断言，如果您无法通过 DAO 创建某些东西，那么根据定义，它不是 Jet 的“原生”。

对我来说，这个“原生”的定义似乎放错了地方。有许多 Jet 对象，出于历史和 Microsoft 政治原因，在 DAO 中省略或仅部分实现（CHECK约束、固定宽度数据类型、DECIMAL数据类型、可压缩数据类型等），但包含在 Jet 的 SQL 中数据定义语言(DDL)。直觉告诉我，Jet SQL DDL 应该被认为是 Jet 引擎的“原生”。

所以我的问题是：为什么一项看似外部的技术 (DAO) 会被视为“本地”，而另一项看似内部的技术 (SQL DDL) 会被视为“非本地”？我是否应该为某些东西是“本地的”还是其他东西而烦恼？

我正在努力提高我的设计模式技能，我很好奇这些模式之间有什么区别？它们看起来都是一样的——封装特定实体的数据库逻辑，因此调用代码不知道底层持久层。根据我的简短研究，它们通常都实现了您的标准 CRUD 方法并抽象出特定于数据库的细节。

除了命名约定（例如 CustomerMapper vs. CustomerDAO vs. CustomerGateway vs. CustomerRepository）之外，有什么区别（如果有的话）？如果有区别，你什么时候会选择一个而不是另一个？

在过去，我会编写类似于以下的代码（自然是简化了 - 我通常不会使用公共属性）：

并有一个CustomerGateway为所有方法实现特定数据库逻辑的类。有时我不会使用接口并将 CustomerGateway 上的所有方法都设为静态（我知道，我知道，这使得它的可测试性降低）所以我可以这样称呼它：

这似乎与 Data Mapper 和 Repository 模式的原则相同；DAO 模式（我认为这与网关相同？）似乎也鼓励特定于数据库的网关。

我错过了什么吗？有 3-4 种不同的方式来做同样的事情似乎有点奇怪。

假设我有一个包含 Dog 对象集合的 Person 类。这种关系是双向的。

好的，如果我只是在处理这些对象，我将在 Person 中有添加狗和删除狗的方法，这样客户端就不会直接使用集合。

或类似的规定。

我的问题是在服务层中使用这些对象时出现的。我可以通过 addDog 向一个人添加一条新狗，然后简单地保存将自动保留新狗的人。但是，通过 removeDog 删除狗然后保存人不会自动从持久存储中删除狗......它只会将狗引用设置为 null。

所以我最终得到了类似的东西：

因为这是一个 web 应用程序，并且 Persons 和 Dogs 不在内存中维护，所以它工作正常，我从未调用过 Person.removeDog()。下次我加载最初引用这条狗的人时，它不会包含这条狗，因为它已从存储中移除。同样的事情也适用于添加狗：

同样，这甚至可以正常工作，而且我从未调用过 Person.addDog()。

那么在我的 Person 类中使用 addDog 和 removeDog 方法有什么意义吗？

我有一个包含 PortalAccount 对象的 Contact 类。当我想为联系人创建“门户帐户”时，使用soap/axis 在门户应用程序上远程创建一个帐户，然后填充联系人的portalAccount 并保存联系人（本地数据库保存有关远程帐户的信息，例如用户 ID 和用户名等）。

因此，我有一个服务类 PortalServiceImpl，它具有在给定 Contact 实例的情况下在远程门户上实际创建用户的方法。

鉴于所有这些信息，我的问题是：PortalServiceImpl 是否应该获取 ContactDAO 对象的实例并实际进行保存，或者 PortalServiceImpl 类是否应该只创建远程用户，修改传入的 Contact 对象，然后让客户端负责储蓄？

方法一：

方法二：

这两种方法对我来说都是错误的。方法 1 感觉不对，因为 PortalService 正在创建一个远程用户并将联系人保存到数据库中（尽管是通过 DAO 接口）。方法 2 感觉不对，因为我必须假设 PortalService 正在修改我传递给它的联系人。

我也有一种感觉，我没有看到其他一些问题，比如可能无法始终如一地处理交易。

（顺便说一句，我已经用过这两种方法了，不想在一个无休止的循环中继续重构。这里似乎有问题。）

我编写了一个在无线网络上运行的小型（8-10 台笔记本电脑）销售点系统，作为一个 HTA，它可以读取/写入位于网络共享上的 Access MDB。
我需要使用 ADO - GetString 并且用户名册不适用于 DAO。
我还需要使用 DAO——不能用 ADO 压缩 MDB。

我知道：
1）如果数据库后端不是Access MDB，我应该使用ADO。
2) 如果后端是 MDB，但我想在某个时候升级到 SQL Server，我应该使用 ADO。
3) 在 Access 应用程序或任何其他 VBA/VB 应用程序中，我应该使用 DAO，因为 ADO 必须经过 Jet OLE DB Provider 的转换层，而 DAO 更直接。
4) VBScript/JScript 允许我使用DAO 或ADO。

分两部分的问题如下：
1）在这个软件环境（HTA/脚本）中，使用ADO比使用DAO更好吗？
2) ADO 是否提供任何好处，因为 HTA 通过无线网络进行读/写？

我正在使用旧版 vb6 产品，我遇到了一个问题，即我需要通过 DAO 从数据库表中获取完整路径的文件名部分。我在这里无法访问 VBA 函数，所以我专门寻找 MS Access SQL。我无法在查询后删除一些额外的代码。除了修改 SQL，我无法更改/重构解决方案。

现在，DAO 没有任何功能instrrev或replace功能，所以我非常有限。

有什么猜测吗？提前致谢。