我应该把我的存储库放在哪个层?

6

方案

数据访问层

  • EF生成的.edmx和类
  • 仅用于访问SQL数据库并将数据传递到业务层

业务层

  • 业务实体: 包含所有验证逻辑,标记有[DataContract]属性,以便可以将它们作为参数传递给我的Web服务

问题

我想使用存储库模式来处理这个方案。存储库将包含要在数据库上执行的所有CRUD操作,接受并返回业务层实体。这意味着存储库将位于业务层中,因为只有业务层可以引用数据层,而不是相反。我还计划在其他项目中使用数据层程序集,这就是为什么我希望将存储库放在数据层中,而不是业务层中(这对于此项目是特定的)。
你有什么建议吗?我应该在业务层中保留存储库并为每个不同的业务层编写一个存储库吗?还是应该将存储库保留在数据层内,不接受或返回业务实体。
或者,作为另一种选择,有没有人可以推荐一个不同的方法,以获得更合理、可扩展的架构?

感谢阅读,等待回答


这正是我所拥有的问题。我正在考虑将我的业务实体分离到一个新的DataContracts程序集中。因此,业务层和数据层都将引用这个DataContracts。 - digaomatias
3个回答

10

一个仓库是数据层的抽象,为应用程序提供持久性无知。它只处理数据访问,不涉及任何业务逻辑。

仓库可以并且应该接受和返回DTO(数据传输对象)-这些是简单的对象,没有自己的行为,并用于在层之间传输数据。

我会将它放在DAL和BLL之间,并且仅从BLL中使用它进行数据访问。


实际上,在智能客户端应用程序中,您也可以拥有客户端存储库... - Ladislav Mrnka
1
那我应该像这样传输数据吗 实体框架实体 <-> DTO's <-> 业务层实体? 对我来说,这看起来很繁琐,特别是因为所有DTO所做的就是在层之间移动数据。 - scripni
@scripni - 这就是 DTO 的目的,对吧。可能会增加一些开销,但你能获得更清晰明了的代码,不需要传递行为,而且对象的职责也更加明确。 - Oded
我使用内存缓存。因此,我的数据层由数据库项目和Datacache项目组成。在这两个项目之上,我有Repository。Repository负责数据访问和缓存。业务层调用repo层,并根据请求的功能显式或隐式地触发DataCache层的缓存。我的DTO位于所谓的Infra层中。这样它们就可以自由地移动到任何需要的地方。通常情况下,我会在除了数据库项目以外的所有项目中使用它们。 - user20358
在DAL和BLL之间放置Repository的示例有吗? - StepUp

7

我喜欢被接受的答案。理想情况下,有一个完全专门用于存储库的层听起来很合适。

但是,我认为,在传统的三层应用程序(例如,“数据->业务->UI”),我会将Repositories放在数据层中。我之所以将它们放在数据层中,是因为它们严格处理数据访问。我不会将它们放在业务层中,因为它们不应该具有任何业务逻辑。


2

我认为仓库接口应该在业务层中,但是这个接口的实现应该在数据层中。接口可以进行单元测试,但是仓库实现不是业务层的职责。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接