问题标签 [poeaa]

我正在编写一个 ORM，但不确定存储库的预期行为，或者更准确地说，不确定存储库和工作单元之间的边界。据我了解，存储库可能如下所示：

根据福勒（PoEAA，第 322 页）：

存储库在域和数据映射层之间进行调解，就像内存中的域对象集合一样。[...] 可以将对象添加到存储库中或从存储库中删除，就像它们可以从简单的对象集合中一样。

这意味着以下测试应该可以工作（假设我们已经有一个 Person 持久化，其姓氏是 Fowler）：

这意味着当映射到数据库时，即使没有在某处调用显式 save() 方法，Person 模型也必须由 Repository 自动持久化，以便下一个查询返回正确的集合，而不包含原始 Person。

但是，这不是工作单元的角色，决定将哪个模型持久化到数据库，以及何时持久化？

在上述实现中，Repository 必须决定在接收到另一个 find() 调用时将之前检索到的 Person 持久化，以便结果与修改一致。但是，如果没有发出其他 find() 调用，则模型根本不会被隐式持久化。

在工作单元的上下文中，这不是一个真正的问题，因为我们可以在开始时启动一个事务，并在需要时将任何插入回滚到数据库。但是当单独使用时，这个 Repository 不会导致意想不到的、不可预测的行为吗？

我最近一直在阅读 TableData Gateway 和 RowData Gateway。根据“企业应用程序架构模式”，RDG 一次处理一条记录，而 TDG 处理整个表。但这两种模式看起来非常相似，它们封装了 SQL 查询并根据我们所做的查询在记录集中返回一条记录或多条记录。我真的不知道什么时候更喜欢 TDG 而不是 RDG。用一些解释来澄清差异会非常有帮助。根据 Martin Fowler 的说法，TDG 是返回一条记录时与RDG相同。但是我们也可以将RDG用于多条记录！那为什么要使用TDG。任何帮助将不胜感激。谢谢你。

嗨，我刚刚读了《企业应用程序架构模式》一书。他们说你应该分层做企业应用程序，你不应该让一层使用上面的层，只使用向下的层......就像域层可以使用 DB 层，但反之亦然。然后有一章是关于创建域对象的 DataMappers。我有点想知道为什么他可以让DB层中的DataMapper在域层中创建一个对象，因为它不遵循底部不调用上层的规则。所以我的问题是实际上不应该是 DB 层中的域对象，或者什么是在不使 DB 层使用域层的情况下制作域对象的好方法

在 Fowler 的“企业应用程序架构模式”一书中，没有提到存储库模式的持久特性。“持久性功能”是指更新、保存、添加或删除实体的功能。只是对一组域对象的纯匹配机制。

另一方面，让我们看看 Mike Hadlow 的博客文章Using the IRepository pattern with LINQ to SQL。有一些具体的持久化方法，比如插入和删除。

那么存储库模式应该如何实现呢？你们能否请我指出好的“真正的”存储库实现。我对这个话题有些沮丧。

提前致谢！希望得到您的帮助！

在 Martin Fowler 的“企业应用程序架构模式”中，描述了用于组织 DAL 的方法，例如一组实体映射器。每个都有自己的 IdentityMap 存储特定实体。

例如在我的 ASP.NET WebApplication 中：

}

问题是：在哪里存储这些映射器？系统服务（实体）应该如何调用映射器？

我决定创建包含所有映射器的 MapperRegistry。因此服务可以调用映射器，例如：

但是我可以在哪里存储 MapperRegistry 实例？我看到以下变体，但不喜欢其中任何一个：

1. MapperRegistry 是全局应用程序（单例）

   • 不适用，因为在多线程 ASP.NET 应用程序中需要同步（至少 Martin 说只有 mad 可以选择此变体）

2. 每个会话的 MapperRegistry

   • 好像也不太好。所有 ORM（NHibernate、LINQ to SQL、EntityFramework）大师都建议对每个请求使用 DataContext（NHibernateSession、ObjectContext），而不是在 Session 中存储上下文。
   • 同样在我的 WebApp 中，几乎所有请求都是对 EntityController.asmx（具有属性 ScriptService）返回 JSON 的 AJAX 请求。并且不允许会话。

3. 每个请求的 MapperRegistry

   • 有很多单独的 AJAX 调用。在这种情况下 MapperRegistry 的生命周期将太小。因此，数据几乎总是会从数据库中检索出来，因此性能低下。

亲爱的专家，请帮助我解决架构问题。

我正在做 zend 项目，我指的是其他 zend 项目来创建新的 Zend 项目。但我不喜欢在没有理解的情况下盲目地遵循该项目。在 Zend Directory 结构中，在 Model 类中，我看到的主要有两种类型的类，如

为什么要遵循这个特定的结构？这是为了分离对象类和数据库模型类吗？

请解释。

在我的模型层中，我有数据映射器、域对象和“服务”（位于模型层之外）。我选择实现 DomainObjectFactory 和 DataMapperFactory，这让我陷入了 DM<->DO 关系。理想情况下，数据映射器将为执行“get”/“read”的每个方法返回相关域对象的实例（或实例数组），但数据映射器无权访问域对象工厂。

如果没有 DM 和 DO 上的工厂模式，自动加载器可以在 DM 中接管，以便可以创建 DO 的实例。但是，这是如何通过工厂实现的呢？

我能想到的一种可能的解决方案是将相关域对象的实例传递给数据映射器方法，例如：

这个选项看起来很脏，但它适用于单个 get 方法。然而，在处理返回域对象数组时，它在语义上脱轨了，所以显然这不是实现这一目标的最佳方法......另一个选择是允许数据映射器访问域对象工厂，但这会变成大规模的 LOD/SRP 违规。

简而言之： 数据映射器如何访问域对象工厂才能返回域对象？

SQL Server 中的单个 BLOB 列将如何比较（性能方面）与约 20 个 REAL 列（20 x 32 位浮点数）？

我记得 Martin Fowler 建议使用 BLOB 来持久化大型对象图（在企业应用程序架构模式中）以删除查询中的多个连接，但是对于具有 20 个固定列的表（从未在查询）？

该表更新非常频繁，大约每秒 100 次，并且INSERT查询中指定的所有列的语句变得相当大。

我认为第一个答案是“自己分析”，但我想知道是否有人已经有这方面的经验。

最近，我在 poeaa 中读到了行数据网关模式。

我的问题是，行数据网关模式的返回值是多少。它是网关对象本身吗？如果是这样，这不会增加 DAL 和 BLL 之间的依赖关系吗？

我的意思是，就像在存储库模式中一样，我们有一个关系：DAL -> BLL，例如：

但是在网关中，关系是这样的：BLL -> DAL，例如：

我是不是误会了什么？

Martin Fowler 提出的 Query Object 模式和 Eric Evans 提出的 Specification 模式有什么区别？