C#存储库-如何与其他存储库交互

我正在重构一些代码，并将一些执行数据库CRUD操作的方法提取到它们自己的存储库类中

考虑到数据库中存储的以下两种类型的对象：用户和角色，我有几个问题

我应该创建IUserRepository和IRoleRepository吗

当执行诸如为用户分配角色之类的操作时，该方法（AssignRoleToUser）应该位于何处？在IUserRepository或IRoleRepository中

如果我想添加一些更复杂的逻辑，比如说，IUserRepository.AddUserAndRoles接受一个IUser，但也接受一个IRole数组， IUserRepository是否应该将IRoleRepository注入其中

1.我应该创建IUserRepository和IRoleRepository吗

是否需要对

用户

和

角色

执行操作？如果是，则创建两个。如果你不需要两者，但将来可能需要，那么不要创建它，只在需要时创建它

2.当执行诸如为用户分配角色之类的操作时，该方法（AssignRoleToUser）应位于何处？在IUserRepository或IRoleRepository中

将角色分配给用户时，很可能会将用户添加到角色中。因此，如果方法位于

角色

存储库中，则可读性更高

3.如果我想添加一些更复杂的逻辑，比如说，IUserRepository.AddUserAndRoles接受一个IUser，但也接受一个IRole数组，那么IUserRepository是否应该向其中注入一个IRoleRepository

在顶部使用一个层，该层将与

用户

和

角色

存储库交互，并在那里执行复杂的工作

尽量不要从您的存储库中返回

IQueryable

，但是，请记住在这方面有两种观点。但是，如果出于性能原因必须用存储过程替换某个操作，或者引入软删除标志，您将感谢我。如果不公开

IQueryable

（s），则将在存储库中进行更改。但是如果您公开了它，您将需要查找所有查询并在任何地方更改它们。人们忘记了，当他们用Linq（到EF或SQL）编写查询时，他们仍然在编写查询，但唯一的区别是他们在用C#编写查询。如果他们是用SQL编写的，他们会三思而后行

---

另外请注意，不要从所有存储库中的经典CRUD、FindAll等开始。我见过许多这样编写的存储库，然后我问了一个问题：但是我们不删除订单，那么为什么我们在

Order

存储库中有一个delete？确保存储库反映您对对象执行的操作。如果您只需要一个

R

（脱离CRUD），那么只需创建一个

Read

方法。如果需要查找，请将其添加到其中。根据需要添加方法。如果您还不需要，就不要编写代码。

为什么要有这么多存储库，不能只有一个吗？@LeiYang这是个好问题。我不确定什么是最佳做法。我不希望我的代码被大量的方法所膨胀，我不是专家。但我认为您可以从实体框架中学到一些东西，一个数据库只有一个dbcontext，这就足够了。业务逻辑应该驻留在服务中。您需要的是一个服务类，它依赖于这些存储库并从中检索数据，执行复杂的逻辑并将数据保存回存储库。相互依赖的存储库必须是最后一个选项。感谢您的回复！我希望自己走上了正确的道路，并在考虑这一点。我的主要动力是能够通过模拟存储库来测试业务逻辑层。我的数据库的一部分由实体框架控制，还有一些其他表不是EF（additions）的一部分，由手动SQL脚本控制。您是否建议在存储库中甚至放置EF层？是的，因为对EF的查询仍然是查询。有些人不会同意，但他们很可能正在开发一次性应用程序。但是，我也不想在这里发动战争，所以要各自为政。但是是的，既然你问我，我就答应了。我自己也总是这样做，除非我在做POC或短期应用程序。