5

我们即将启动一个类似于前一个的新项目。我可以复制旧设计,但我对旧设计不太满意。在WinForms中使用Entity Framework和存储库模式MDI

它是建立在.Net 3.5(Winforms MDI)的后台的Entity Framework上的“标准”业务系统(销售,库存,仓储等)。

所有窗体都继承自一个baseform(继承Windows.Form)。表单公开了一个名为ObjectContext的属性,它在第一次调用时实例化一个新的ObjectContext。这构成了一个相当不错的UnitOfWork,我认为所有的数据访问都在每个表单中分离出来。

但是,

我已将所有查询和常见CRUD封装在“可怜的人库”中。这些存储库作为ObjectContext的属性公开。

所以,如果我想绑定和订购一个窗体,我会打电话 OrderLinesGrid = ObjectContext.OrderRepository.GetOrderLinesByID(orderID)。

的OrderRepository获取到的形式创建的ObjectContext的一个参考,这样

(在我的部分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 

我不喜欢这样的:

  1. 通过ObjectContext将对库的调用设置为 。因此,我做 没有得到 查询和数据访问层我想 之间的抽象。

  2. 对于每一个新类型我的域名我 需要在我 ObjectContext的创建属性

我呼吁OrderRepository应该只返回域对象,而不用担心它是如何坚持。另外,我不能让每个Repository都拥有它自己的ObjectContext,因为这会要求我在将Country引用到Order.Country属性时附加和分离对象。

我希望这种设计:)

回答

0

我建议你研究"onion" principleRepository pattern和LUW模式的任何想法和反馈。 网络上有很多例子。

本质上你使用POCO模型核心项目。没有对DAL项目的引用。 您在CORE项目中声明Repository和luw模式的接口。

所以现在

UI layer -> instantiate context and DAL Object eg repository -> inject into CORE services. 

也连接到该方法是控制或依赖注入模式的反演。

如果您对虚拟存储库使用测试驱动开发,则可以确保遵循设计原则。