經典架構定義了以下幾個部分:
DAL(數據訪問層):涉及數據庫操作,不包含業務邏輯。 BLL(業務邏輯層):處理業務邏輯和約束,但沒有數據庫操作。 PL(表示層):處理演示和用戶交互。
MVP/MVVM只處理PL。最大的問題是,這種模式中的M(odel)到底是什麼。一個例子是使用Entity Framework或DevExpress XPO將對象映射到數據庫。但是這是什麼東西?他們是虛擬機嗎?他們是模型嗎?或者他們只是Dal的簡單DOT?如果你看看以前的定義,最後一個將是最匹配的一個。但是這意味着你必須將這個dt映射到你的模型對象(邏輯所在的地方)和你的vms(數據綁定發生的地方),或者先到你的模型,然後再從那裏到你的vms?數據網格的過濾/排序/分頁功能如何,只有在您直接訪問您的dal時纔有效?
在我看來,三個方面的真正分離只能通過CQRS或類似的體系結構來實現。至少我不知道別人。但是,這僅適用於擁有大量業務邏輯的極其複雜的應用程序,並且會帶來很多開銷和折衷。
因此,對於您的應用程序,您必須決定哪些障礙可以打破您的需求並避免爲您的項目帶來不必要的複雜性。一個簡單的CRUD應用程序可以使用實體框架/ XPO,並直接將對象用作虛擬機進行數據綁定。你根本沒有任何感覺。如果它變得更加複雜,你可能會朝着cqrs的方向走。您可以定義視圖並直接使用EF/XPO及其對象進行數據綁定,但是對於複雜的操作,您可以使用執行這些操作的對象(使用EF/XPO加載的對象)創建一個bll(域)模型(之後需要重新加載vms )。如果它更復雜,那麼可以通過事件採購和可能用DDD建模來完成CQRS的完整方法。