我们即将启动一个与之前的项目类似的新项目。我可以复制旧的设计,但我对旧的设计不太满意。
它是一个“标准”业务系统(销售、盘点、仓储等),构建在.Net 3.5(Winforms MDI)之上,后端带有实体框架。
所有窗体都继承自基本窗体(它继承 Windows.Form)。该表单公开了一个名为 ObjectContext 的属性,该属性在第一次调用时实例化一个新的 ObjectContext。我认为这构成了一个非常好的工作单元,在每种表单中隔离了所有数据访问。
However.
我已经将所有查询和常见的 CRUD 封装在“poor mans repositories”中。这些存储库作为 ObjectContext 的属性公开。
因此,如果我想绑定并订购表单,我会调用
OrderLinesGrid = ObjectContext.OrderRepository.GetOrderLinesByID(orderID)。
OrderRepository 获取对为表单创建的对象上下文的引用,如下所示
(在我的部分 ObjectContext 类中)
Private _OrderRepository as OrderRepository
Public ReadOnly Property OrderRepository as OrderRepository
Get
if _orderrepository is nothing then
_orderrepository = New OrderRepository(me)
end if
return _orderrepository
End Get
End Property
我不喜欢这个的是:
对存储库的调用已完成
通过对象上下文。因此,我做
没有得到之间的抽象
查询和数据访问层 I
想。
对于我的域中的每个新类型我
需要在我的中创建一个属性
对象上下文
我对 OrderRepository 的调用应该只返回域对象,而不用担心它是如何持久化的。另外,我不能让每个存储库都有自己的 ObjectContext,因为这需要我在引用(即 Country)到 Order.Country 属性时附加和分离对象。
我将不胜感激对此设计的任何想法和反馈:)
我建议你研究一下“洋葱”原则 http://jared-jenkins.com/onion_arch_presentation/#title-slide , 存储库模式 http://www.codeproject.com/Articles/561584/Repository-Pattern-with-Entity-Framework-using和卢夫模式。
网络上有很多例子。
本质上,您使用 POCO 模型核心项目。没有提及 DAL 项目。
您在 CORE 项目中声明 Repository 和 luw 模式的接口。
所以现在
UI layer -> instantiate context and DAL Object eg repository -> inject into CORE services.
与此方法相关的还有控制反转或依赖注入模式。
如果您对虚拟存储库使用测试驱动开发,则可以确保遵守设计原则。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)