![]() |
1
2
在我看来,这方面没有最佳实践。它更受项目的实际需求以及这些存储库将如何使用的驱动。
我的指导原则是“什么是我的主要实体,什么是我的从属实体”。假期或休假离不开员工,所以我可以想象一个员工信息库,上面写着:
依赖实体的id在这里并不重要,因此单独的存储库可能会有点过头。 如果您决定使用350个存储库,我至少会考虑一下通用存储库基类,它将为您提供通用的GetById、Save、Find等方法。而不是只扩展那些逻辑性更强的存储库。我认为这不会超过50个,而且从第一个方法来看,这些或多或少是你的“主要实体”。 总之,这一切都是自以为是的,最终取决于你,你的个人喜好和你的项目需求。 |
![]() |
2
0
对我来说,更重要的是业务层不应该直接与实体合作。相反,BL使用一个域或某种类型的DTO,然后传递到一个存储库,该存储库处理的类型是“嘿,为我保存这个”。然后,存储库本身将该域/dto带到BL知道的项中,然后将其转换为您想要用来持久化它的任何实体/技术(EF/Dapper)。将来,如果您需要将其发送到WebApi调用,您可以在那里对其进行更改,而上面的任何内容都不会在意。但是很明显,由于它是对业务类型的实体作出反应,所以最终几乎得到了业务存储库,但我认为它提供了最大的灵活性。 编辑:示例:
您还可以拥有一个通用存储库,如:
|
![]() |
M.Sabzi · 如何在应用层实现随子集合创建? 7 年前 |
![]() |
JJ Yong · 继承的通用存储库问题 7 年前 |
![]() |
Utku · 实体框架,从多个表中获取数据并选择要显示的列 7 年前 |
![]() |
koryakinp · 基于实体类型的通用存储库应用过滤器 7 年前 |
![]() |
Pedro Lopes · 尝试通过存储库编辑数据库中的数据时获取验证 7 年前 |
![]() |
The Huff · IOption模式-单元测试和通过层 7 年前 |