问题标签 [repository-pattern]

我正准备开始一个新的 asp.net web 项目，我将使用 LINQ-to-SQL。我使用Mike Hadlow找到的一些信息做了一些工作来设置我的数据层，这些信息使用接口和泛型为数据库中的每个表创建一个存储库。起初我认为这是一种有趣的方法。但是，现在我认为创建一个基础 Repository 类并从它继承以为我需要访问的表创建一个 TableNameRepository 类可能更有意义。

哪种方法可以让我以干净可测试的方式添加特定于表的功能？这是我的存储库实现供参考。

我正在为我的 ASP.net MVC 应用程序寻找遵循域驱动设计原则的存储库模式实现示例/资源。有没有人可以分享一个很好的例子或学习资源？

我正在写一个存储库。获取对象是通过 DAO 完成的。创建和更新对象是通过一个 Request 对象完成的，该对象被赋予一个 RequestHandler 对象（一个命令模式）。我没有编写 DAO、Request 或 RequestHandler，所以我无法修改它们。

我正在尝试为此存储库编写测试。我已经模拟了 DAO 和 RequestHandler。我的目标是让模拟的 RequestHandler 简单地将新的或更新的对象添加到模拟的 DAO。这将产生我正在与数据库交谈的错觉。这样，我不必为调用此存储库的所有类模拟存储库。

问题是 Request 对象是这个字符串 blob 和各种字母数字代码的 gob。我很确定 XML 也参与其中。这有点乱。另一位开发人员正在编写代码以根据所存储的对象创建 Request 对象。而且由于 RequestHandler 接收请求而不是我存储的对象，因此它无法更新模拟的 DAO。

所以问题是：我是否也要模拟请求，还是应该等到其他人，他有点慢，在我编写测试之前完成他的代码？或者在测试调用存储库的类时搞砸并模拟整个存储库？

顺便说一句，我说的“模拟”不是 NMock 意义上的，而是像用内存中的集合来伪造数据库一样。

我查看了存储库模式，我发现了一些我过去使用的想法，这些想法让我感觉很好。

但是现在我想编写一个使用这种模式的应用程序，但我希望实体类与存储库提供者分离。

我会创建几个程序集：

1. 一个“接口”程序集，它将承载包括 IRepository 接口在内的通用接口
2. 一个“实体”程序集，它将承载产品、用户、订单等实体类。该程序集将由“接口”程序集引用，因为某些方法将返回此类类型或它们的数组。它也将被主应用程序程序集（例如 Web 应用程序）引用
3. 一个或多个存储库提供程序程序集/程序集。每个都将包括（至少）一个实现 IRepository 接口的类，并且它将与某个数据存储一起使用。数据存储可以包括 SQL Server、Oracle 服务器、MySQL、XML 文件、Web/WCF 服务等。

在我发现生成的类和 CustomDataContext 类之间存在深度依赖之前，研究 LINQ to SQL 看起来在实现所有方面所花费的时间方面看起来非常有成效。

在这种情况下如何使用 LINQ to SQL？

假设您有规范的客户域对象。您在三个不同的屏幕上显示客户：外部管理员、内部管理员和更新帐户。

进一步假设每个屏幕仅显示 Customer 对象中包含的所有数据的一个子集。

问题是：当 UI 从每个屏幕传回数据时（例如通过 DTO），它只包含完整客户域对象的子集。因此，当您将该 DTO 发送到客户工厂以重新创建客户对象时，您只有客户的一部分。

然后您将此客户发送到您的客户存储库以保存它，一堆数据将被清除，因为它不存在。悲剧接踵而至。

所以问题是：你将如何处理这个问题？

我的一些想法：

• 在存储库中包含一个参数，指示要更新客户的哪一部分，并忽略其他部分

• 当您加载客户时，将其保存在静态内存中、会话中或任何地方，然后当您从 UI 接收到其中一个 DTO 时，仅更新与 DTO 相关的部分

IMO，这两者都是kludges。还有其他更好的想法吗？

@chadmyers：这是问题所在。

实体具有属性 A、B、C 和 D。

DTO #1 包含 B 和 C 的属性。

DTO #2 包含 C 和 D 的属性。

UI 要求 DTO #1，您从存储库加载实体，将其转换为 DTO #1，仅填写 B 和 C，然后将其提供给 UI。

现在 UI 更新 B 并将 DTO 发回。您重新创建实体，它只填写了 B 和 C，因为这就是 DTO 中包含的全部内容。

现在您要保存仅填充了 B 和 C 的实体，其中 A 和 D 为空/空白。存储库无法知道它是否应该将持久性中的 A 和 D 更新为空白，或者是否应该忽略它们。

快速提问：将我的领域驱动设计风格存储库实现为单例是个好主意还是坏主意？为什么？

或者我应该使用依赖注入器容器来管理我的存储库并确定它们是否是单例？

我仍在快速阅读 DDD，并希望看到一些好的存储库示例。

我使用 MVC 框架已经有一段时间了，我真的很喜欢如何分离关注点。我养成了让控制器做大量工作的坏习惯。所以我真的在寻求一些建议。

当我第一次开始使用 MVC 时，我经常在数据库工作完成后让控制器对模型进行操作。我知道这很糟糕，所以将这项工作转移到模型中。但是我对此并不满意，因为我希望我的模型非常好学。

我做了一些阅读，我看到人们通过服务层来保持他们的控制器和模型的精简，我喜欢它的外观。

我只是想了解服务层和存储库应该如何协同工作。这是我的假设，请告诉我这是否是一种好的工作方式？

1. 如果不需要对数据进行任何操作，控制器可以直接调用存储库，因此服务层不需要参与
2. 一旦需要对数据（业务逻辑）进行任何工作，则应在服务层中完成，控制器将在需要时对服务层进行简单调用
3. 一旦服务完成了它的业务逻辑，它将根据需要使用存储库（如果需要持久化数据）。
4. 理想情况下，模型应该保持精简，理想情况下只是充当 DTO
5. 数据验证将在模型内完成（使用 MonoRail 验证属性）。我很欣赏甚至没有人喜欢用很多属性污染他们的模型，但这是一个不同的讨论。我喜欢 MonoRail 的验证属性在 UI 中自动 jQuery 验证的好处。

我试图将我的所有代码都转向单一责任原则，因此试图整理我的编码实践。

谢谢

我想知道是否有人对如何做到这一点有更好的想法。自动取款机返回对我IQueryable<Member>来说ObjectQuery<Member>似乎很脏。

我正在使用通用存储库接口，它允许我添加、查找、更新和删除不同类型的对象。然后我实现了两个具体的存储库，并且可以在不更改应用程序的情况下切换它们。一切都奇妙地脱节。但我遇到了一个障碍。我的存储库方法中的代码感觉不对，我不知道如何做得更好。这是我的代码片段：

问题是我的 DataAccess（从数据读取器创建对象）不是通用的，并且对于它支持的每种类型的对象都有特定的方法。

我可以重写上面的内容，以避免使用泛型或其他方式的 if-then-elseif 列表吗？

我一直在阅读一些关于 ASP.NET MVC、SOLID 等的内容，我正在尝试为中小型 ASP.NET MVC 应用程序找出一个简单的“配方”，将这些概念结合在一起；我最关心的问题是控制器过于复杂，就像 web 表单中的代码隐藏文件，其中包含所有类型的业务逻辑。

对于小型数据驱动的应用程序，我正在考虑以下架构：

• 控制器：只处理请求，调用相应的服务并将动作结果返回给视图；
• 模型：POCO，处理所有业务逻辑、授权等。依赖于存储库，完全不了解持久性基础设施。
• 存储库：实现IRepository<T>，使用依赖注入，是我的数据库代码所在的位置；只接收和返回 POCO。

我正在考虑在控制器和模型之间提供服务，但如果它们只是传递方法调用，我不确定它会有多大用处。

最后应该有覆盖模型代码的单元测试，以及覆盖存储库代码的单元+集成测试（如果可能，遵循“红绿”实践）

想法？