问题标签 [repository-pattern]

我正在寻找一个好的实体框架存储库代码示例或模板。

我是存储库模式的新手，在网上做了很多阅读之后，我对正在发生的事情有了一个粗略的了解，但似乎存在思想冲突。

一个是 IRepository 应该返回的内容。

我只想处理 Pocos，所以我将为每个聚合根都有一个 IRepository 实现，如下所示：

其中 IOrangeCriteria 采用一些特定于查找橙色的参数。

我拥有的另一件事是许多数据后端——这就是我首先进入这种模式的原因。我想我将为每个人都有一个实现，例如

OrangeRepositoryOracle、OrangeRepositorySQL、OrangeRepositoryMock 等

我想让它保持打开状态，以便我可以使用 EF 或 NHibernate - 如果我的 IOrangeRepository 处理 POCO，那么我将通过实现 OrangeRepositoryNHibernate 等将其封装在存储库本身中。

我在正确的路线上吗？

谢谢

编辑：感谢您的反馈，目前我没有其他人可以提出这些想法，因此不胜感激！

大家好。我遇到了使用存储库和服务模型的奇怪设计模式。该应用程序由 ASP.NET MVC、WCF 和一些 Windows 服务组成。我的存储库正在使用 LINQ DataContext。随着我的应用程序的发展，我发现自己到处都在传递对 IWhateverService 服务的引用。例如，我有 IAccountService，它定义了诸如 ChangePlan(Account account, Plan plan) 之类的方法。

现在，似乎 IAccountService 是放置此方法的最佳位置，因为我们在这里为帐户提供服务。但是，ChangePlan 方法需要知道几件事才能真正更改计划。它必须知道用户的当前使用情况、可用计划列表、用于计费的电子商务服务接口的实例等。

我认为让 ChangePlan 方法接受 IAccountService 接口中的所有必需服务。但是这些其他服务的要求是一个实现问题，不应该是接口定义的一部分。

因此，现在我发现自己为 AccountService 创建了一个巨大的构造函数，其中包含 IAccountRepository、IPPlanService、IUsageService、IEcommerceService 和 IValidationDictionary 的实例。这感觉根本不对。

现在以这种情况为例。显然 IAccountService 包含一个通过 ID 检索用户帐户的简单方法： Account Get(int id) 有几次我只需要调用这个方法。所以，我去创建我的 AccountService，它需要所有这些其他服务的实例（尤其是 IValidationDictionary，我不需要对此进行验证）。再一次，这感觉不对。我可以传递 null，但这只是因为我知道实现不会仅将它们用于此方法。

此外，为了避免在需要的任何地方实例化服务，我创建了一个名为 ServiceFactory 的静态类，它具有静态方法、CreateAccountService、CreatePlanService 等……我在应用程序周围调用这些方法。看起来不错，但我无法摆脱这种不合适的感觉。

我的断线在哪里？有人有什么建议吗？

谢谢。

安德鲁

我有至少 2 个其他类使用的存储库类。这个存储库类需要初始化——成本很高（查询数据库）。现在，我在需要的地方创建单独的存储库实例。问题是，每次我创建存储库时都必须对其进行初始化。如何将这样的存储库设计为对 TDD 友好？我首先想到的是 Singleton，但这不是解决方案。

如果您创建了一个存储库类，它封装了给定实体的所有持久性逻辑，例如 PersonRepository，但您的存储库类没有实现工作单元模式或身份映射模式，它是否仍被视为存储库？换句话说，存储库实现是否需要工作单元和身份映射，或者我们可以将任何封装了我们的持久性逻辑的类称为存储库？

我应该补充一件事。如果存储库不需要这些模式并且它实际上只是持久性方法的容器，那么存储库和 DAO（数据访问对象）之间有什么区别？我们只是为同一个对象创建了多个名称，还是我们缺少存储库应有的部分内容？

我刚刚开始使用 DDD，所以也许这是一个愚蠢的问题......

实体可以访问存储库（通过某些 IRepository 接口）以在运行时获取值吗？例如，我想对属性强制执行“默认”选择：

我的问题是，做这样的事情是否严重违反了 DDD 原则。如果不是，我的下一个问题是提供存储库以供使用的最佳方式是什么？是否应该在创建 Person 对象时提供？

谢谢，P

我已经使用 Rob Conery 对存储库模式（来自 MVC Storefront 项目）的旋转实现了一个 DAL，其中我使用 Linq 将数据库对象映射到域对象，并使用 Linq to SQL 来实际获取数据。

这一切都很好地让我完全控制了我想要的域对象的形状，但是我遇到了一个我想在这里问的并发问题。我有并发工作，但解决方案感觉它可能是错误的（只是其中一种混乱的感觉）。

基本模式是：

因此，通过该实现，由于映射到域任务，我失去了并发跟踪。我通过存储私有表来取回它，这是我在获取原始任务时的任务数据上下文列表。

然后我从这个存储的表中更新任务并保存我更新的内容

这是有效的 - 当存在并发冲突时，我会收到更改冲突异常，就像我想要的那样。

然而，它只是对我尖叫，我错过了一个把戏。

有没有更好的方法来做到这一点？

我已经查看了 datacontext 上的 .Attach 方法，但这似乎需要以与我已经在做的类似的方式存储原始版本。

我也知道我可以通过取消域对象并让 Linq to SQL 生成的对象一直在我的堆栈中来避免这一切——但我不喜欢这一点，就像我不喜欢我处理并发的方式一样。

按照 Rob 的做法，我拥有由 Linq to SQL 向导生成的类，然后是那些作为 POCO 的类的副本。在我的存储库中，我返回这些 POCO 而不是 Linq to SQL 模型：

我知道这样做的好处是 POCO 模型可以更容易地实例化，因此这将使我的代码更具可测试性。

我现在正在从 Linq 迁移到 SQL 再到 Entity Framework，并且我已经完成了一本 EF 书籍的一半。通过从我的存储库而不是 EF 实体返回 POCO，我似乎会失去很多好处。

我还没有真正接受单元测试，所以我觉得我在浪费大量时间创建这些额外的 POCO 并编写代码来填充它们，而我似乎获得的只是可测试的代码，但我也在由于无法跟踪我的对象，将会失去 EF 的许多好处。

有没有人对所有这些 ORM/Repository 东西的相对新手有任何建议？

安东尼

我一直在研究 NerdDinner 教程，其中大部分内容都很有意义。我不确定的是为什么直接在控制器中使用存储库而不是模型对象。例如，如果我们想实现自己的会员系统，并且它有一个带有 Login 方法的 AccountController，那么连接它的最佳解决方案是什么？例如

或者

或者

我建议让 Account 对象直接使用 AccountRepository，而不是 AccountController 从 AccountRepository 获取信息，然后将其传递给 Account 对象，例如

书呆子风格：

1 登录请求进来
2 AccountController 使用 AccountRepository 根据请求获取登录详细信息
3 AccountController 使用 Account 对象并传入来自步骤 1 的信息
4 Account 对象处理请求并通知 AccountController

我的建议是：

1 登录请求进来
2 AccountController 使用 Account 对象根据请求处理登录
3 Account 对象使用 AccountRepository 获取登录详细信息
4 Account 对象处理请求并通知 AccountController

后一种风格的原因是，在从 AccountRepository 返回登录详细信息后，将遵循业务规则，例如帐户锁定、帐户验证等如果使用第一种风格，则获取详细信息然后使用它们的逻辑是拆分的超过2个步骤。后一种风格将所有逻辑保持在一起，同时仍然使用 AccountRepository 例如

我希望这是有道理的。

我已经实现了一种Repository类，它有GetByID,DeleteByID方法等，但是我在实现该UpdateByID方法时遇到了麻烦。

我做了这样的事情：

但它不会更新传递的实体。

有没有人实施过这样的方法？

供参考，方法GetByID如下

[更新]

正如 Marc 正确建议的那样，我只是在更改局部变量的值。那么您认为我应该如何使用这种方法？使用反射并将属性从复制entity到item？