MVP：被动视图（带EF）和图层

我正在使用MVP创建应用程序：被动视图和EF（模型优先）。据了解，我有一位演示者直接从通过EF创建的DataContext获取数据。它看起来是这样的：MVP：被动视图（带EF）和图层

 private void UpdateOrderTableControl() 
    { 
     IList<Order> orders = dataContext.Orders.ToList(); 
     IList<OrderViewModel> viewOrders = new List<OrderViewModel>(); 
     foreach (var o in orders) 
     { 
      viewOrders.Add(new OrderViewModel() 
      { 
       OrderId = o.Id, 
       CustomerId = o.CustomerId, 
       LastName = o.Address.LastName, 
       FirstName = o.Address.FirstName, 
       Company = o.Address.Company, 
       Weight = o.Weight, 
       Sum = o.Sum, 
       Date = o.Date 
      }); 
     } 

     view.GetOrderDataGridView().DataSource = viewOrders; 
    }

所以演讲得到所有订单的列表，创建订单视图模型的列表（来自不同表的数据组合，即上面的地址），然后发送视图模型列表中视图。

这几乎是同样的事情，周围的其他方式，为了获取从视图中的数据时，编辑或添加到数据库：

 private void SaveOrder() 
    { 
     GetOrderDataFromView(); 

     if (isNewOrder) 
     { 
      dataContext.Orders.Add(selectedOrder); 
     } 
     else 
     { 
      dataContext.Entry(selectedOrder).State = EntityState.Modified; 
     } 

     dataContext.SaveChanges(); 
     isSaved = true; 

     UpdateOrderTableControl(); 
    }

1）可通过EF创建EF（实体时， DataContext等）被认为是DAL？它应该在它自己的项目中吗？

2）我想主持人不应该像这样访问DataContext，而是访问这两者之间的另一个层，对吧？那会是服务层，业务层还是两者？

3）我说的视图模型实际上是一个视图模型还是其他东西？我只想让我的术语正确。

编辑：

4）我读到有关添加业务逻辑由EF生成的实体提出了一些建议，但是，这并不健全的非常正确的我。我应该在EF之上的独立业务层创建业务对象吗？含义我会有订单（由EF生成），OrderBO（业务对象）和OrderViewModel（要显示的订单）。我将不得不做更多的映射，因为我会添加另一个图层，但它会使演示者更轻。

在此先感谢！

来源

2013-08-31 Lahey

不错的问题！

那么，他们的答案都取决于你打算做什么。首先你要做的是评估实施每种模式所需的努力是否值得痛苦。

1）你打算在表单的不同实现之间切换，并且/或者仅为UI单独进行大量单元测试？然后是被动观点似乎是一个好主意。

2）在表单里面使用litle代码不是很痛苦吗？然后MVP supervising controller可以更快实施。

3）您的程序的大部分逻辑能否在业务层内？在BL内部具有所有逻辑之后，GUI具体有多少逻辑？如果它不是那么多，那么没有GUI模式的表单内的代码是要走的路。

关于问题：

1）是的，EF也算是一个DAL，并不会伤害到在不同的项目中。既然你进入模式，这里的有用模式是Repository and Unit of Work Pattern，它抽象出EF并让你单元测试BL。（测试不访问实际数据库，伪造DAL实现）

2）取决于。 EF对象可以被认为是数据传输对象，因为它们是POCO。 DTO在所有图层中都可见。另一个策略是具有特定于图层的对象，主要是在分层应用程序（每个图层位于不同机器中）的情况下。

如果不是被迫做其他事情，我会让EF对象对所有图层都可见，但DataContext本身只对BL可见，而不是GUI层。这意味着查询和事务在BL中完成，但GUI可以以相同的格式获得结果。 3）如果你按照上面的建议，这个相当不好的对象复制是不需要的。

4）这种策略，你指的是Domain Model（谷歌更多），在其中你把逻辑域对象的内部，也可以访问数据库。同样，如果你按照2）中的建议，这不会打扰你。

虽然在对模式及其正确实现感到沮丧之前，真正关注您的需求！ 目标是快速交货和易于维护。过多的抽象会伤害两者！

来源

2013-09-01 16:22:21

关于问题＃2，最好区分并对数据访问层进行抽象。如果您继续将它放在Presenters中，这意味着您的客户端每次都会询问数据库，加载一些数据然后进行一些计算。如果您正在使用Client-Server应用程序，最好不要混淆服务器逻辑和客户端逻辑。演示者绝对在客户端，DAL在服务器端。您可以使用Web服务将客户端连接到服务器（例如asmx，wcf）。我看到至少有三个巨大的原因，要做到这一点：

能力，如果需要写上您的主持人简单的单元测试没有真正的后台和服务器逻辑
Scale的服务器端。
您将可以更少的数据发送给客户端，如果你让服务器端

关于＃3一些必需的计算，在被动视图模式，有一个主持人，该请求数据（有时称为模型），准备显示并发送到视图进行渲染。在Model-View-ViewModel模式中，ViewModel将向服务器发送请求并准备要显示的数据。 MVVM和PassiveView之间的差异Presenters和ViewModel如何与View一起使用。在PassiveView Presenter中将了解View的界面，以便能够发送数据进行渲染。在MVVM View中知道ViewModel并绑定来自ViewModel的数据。

最后一个，＃1。我认为是的，这是一些基础设施层。如果你在这里进行抽象化，你将能够移动一些优化命令，设置加载选项（EF在这里非常灵活），你将能够快速完成。

来源

2013-08-31 18:22:33

谢谢。我又增加了一个问题。 – Lahey

我推荐你阅读一些关于领域驱动设计（DDD）方法的内容。在大多数情况下，业务逻辑是描述业务规则，验证，关系等的单独的层。 –

MVP：被动视图（带EF）和图层

回答

相关问题