在浏览了asp.net mvc的一些教程之后,出现了存储库模式,示例是一个表,即dinners表。基本上,设置是创建一个接口,然后是一个具体的类,它在控制器类中实现接口和程序。接口具有典型的crud方法。如果要使用此模式,是否必须创建每种类型的接口。例如,有一个带有Dinner类型的GetList方法。如果您有10种不同类型需要执行crud功能,该怎么办?这是否意味着10个具有10个具体类的接口只是为了能够将db技术转换到路上? 我试图弄清楚如何将这种模式应用于标准的3层架构(对象层,业务逻辑层,数据访问层)。
感谢。
答案 0 :(得分:7)
这是我通常在我的实施中这样做的方式。
通用接口IEntityRepository,用于定义基本的CRUD结构。在我的实现中,我定义了以下成员:
我创建了另一个继承IEntityRepository的接口IMyentityRepository。这允许我添加任何特定于实体的成员,并且在我需要时仍然能够使用DI。然后我创建我的密封类MyentityRepository,它继承IMyentityRepository并实现所有成员。
使用依赖注入时,可以为具体类型的MyentityRepository注册接口(IMyentityRepository)。
就我而言,我实际上并没有完成。我在存储库顶部创建了一个服务层来封装它并以更通用的方式公开它。例如,假设您要为您的用户创建一个帐户,这可能涉及比简单地创建数据库记录更多的工作。在您的服务中,您将拥有一个名为CreateUser()的成员,该成员可以在其实现中调用多个存储库成员。 我的服务层与我的存储库层一样。我为常见的CRUD成员提供IEntityService,为特定于实体的成员提供IMyentityService,为实现提供MyentityService。 MyentityService类需要一个IMyentityService实例(您可以将其注入您选择的IoC框架)您的服务层也可以进行验证和任何业务逻辑。我在控制器中进行验证。好吧,从技术上讲,我调用它我的控制器并获得结果,然后我可以写入ModelState。
希望有所帮助。
答案 1 :(得分:2)
这可能比您要查找的内容更多,但您可以在S#arp Architecture中查看示例Northwind应用。
存储库位于Northwind.Core项目中。
使用存储库和DI的好处并非如此,您可以在将来某个日期切换底层数据库技术。相反,您可以编写单元测试,您可以在测试中模拟和伪造它们所依赖的类的服务(由接口定义)。
答案 2 :(得分:0)
您是否使用CRUD方法创建一个通用的IRepository类,可以用于任何表,而不是每个表的唯一存储库类。
这是我在做出决定时会问的问题:
“每个存储库是否应支持创建,读取,更新和删除?”
我选择使用自定义存储库类,以便我的界面更明确。例如,我有查找数据表,我不允许插入,更新或删除。这些表的存储库仅包含Get方法。这为我提供了更清洁的设计,但代价是更多的工作。