MVC存储库模式设计决策

Question

我有一个asp .net MVC应用程序,最近开始使用服务验证层实现存储库模式,就像这样.

我一直在为我创建的每个模型创建一个存储库/服务.这有点矫枉过正吗？相反,我应该为每个为许多不同模型提供CRUD的逻辑业务区域创建一个存储库/服务吗？

对我而言,似乎我要么使用许多文件使项目树混乱,要么使用许多方法使类混乱.6单程半打另一半.你能想到任何好的论据吗？

Answer 1

通常,如果您使用的是"真正的"存储库模式,而不是其他持久层(例如ActiveRecord或DAO),则应该确定域聚合,并为每个聚合创建一个存储库.

那是什么意思？嗯,这很大程度上取决于你的应用程序,但通常有些对象自然是其他对象的"父母",或者是相关交易的一部分.

我认为规范的例子是一个电子商务系统,其中你有一个订单的概念,并且在订单中你有订单,每个订单行是一些产品和数量,等等.

在这种情况下,Order对象是系统的聚合根之一,并创建OrderRepository.

在这种情况下要记住的是,订单与其订单线之间存在某种关系(暗示或其他),依此类推.因此,存储库中"CRUD"的C-UD部分通常应该只是一个方法,并且通常应该只接受该聚合根对象的实例并对其进行操作(.eg repo.Save(order)).其他可能的参数可能在那里,但这取决于你的impl.

事实上,你经常可以解决大多数带有继承的C-UD部分(即创建一个RepositoryBase,它使用一些已知的逻辑来实现它们,这些逻辑关于你的特定持久性方案会发生什么样的事情).

因此,这使我们成为CRUD的R部分.在这种情况下,如果您选择查询方法路由,可能会获得大量查询方法(GetById; GetByName; GetByCustomerName等).有些人喜欢(尤其是简单的应用程序)暴露基于linq的界面(例如IQueryable GetAll()),然后可以应用Where子句.YMMV取决于你对它的潜在持久性,但它对于简单的应用程序来说是一个可靠的镜头,尤其是 如果您希望持久性提供程序直接支持linq.

最后,许多人实际上通过Command Query Responsibility Separation模式的一个或另一个实现来分离查询部分,该模式表示持久化和查询的接口应该是不同的.在这种情况下,你有一个Repo只有基本的CRUD(GetById,GetAll,Save,Delete)操作和另一类某种类,它根据你的应用程序的意图查询事物.

希望有所帮助.

保罗