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）和圖層

回答

相關問題