duf*_*ffy 7 asp.net-mvc design-patterns
这次我有一个更哲学的问题.
大多数MVC教程/书籍似乎建议将一个存储库的范围限制为模型的一个方面,并设置多个存储库以涵盖所有模型类.(例如:ProjectRep,UserRep,ImageRep,最终都映射到同一个db.)
我可以看到这将如何使单元测试变得更简单但我无法想象这将如何在现实世界中起作用,在现实世界中大多数实体之间具有相互关系.最后,我总是发现自己每个数据库连接都有一个巨大的存储库类,并且用于单元测试的同样是一个笨拙的FakeRepository.
那么,你有什么看法？我应该更加努力地分离出存储库吗？是否ProductRep通过PurchaseHistory引用UserRep中的数据,反之亦然？当访问单个数据库时,不同的代表如何确保它们不会互相锁定？
谢谢,达菲
这在现实世界中是有效的，因为存储库的底层只有一个引擎。这可以是像 NHibernate 这样的 ORM 或您自己的解决方案。该引擎知道如何关联对象、锁定数据库、缓存请求等。但业务代码不应该知道这些基础设施细节。
当您最终拥有一个巨大的存储库时，您实际上要做的就是将这个单一引擎暴露给现实世界。因此，您的域代码会与隐藏在存储库接口后面的特定于引擎的详细信息混淆。
S#arp 架构很好地说明了 Josh 谈论的存储库是如何实现和工作的。另请阅读 NHibernate 最佳实践文章，其中解释了 S#arp 的大部分背景。
坦率地说，我无法想象你的巨型存储库在现实世界中如何运作。因为这个想法看起来很糟糕而且无法维护。