UI設計模式

Question

我一直在閱讀MVP，MVVM，並在幾個實踐項目中使用了asp.net MVC。這些模式通常被稱爲UI模式，這對我來說有點混亂，因爲我以前認爲只有Views（在MVC中）是UI，Model是數據訪問層+ BLL。 我的問題是，如果我使用實體框架（EDMX）作爲我的模型，爲什麼我需要有一個單獨的數據訪問層（DAL）以及此數據訪問層在這種情況下實際執行的操作。

Answer 1

實際上，視圖和控制器都處理UI。基本上，除了Model Layer之外的所有內容都適用於UI。而且你必須明白，像REST API這樣的東西也只是一種不同類型的用戶界面。

至於你的研究，我會建議你採取更嚴格的模型2 MVC和HMVC看看。前者是最接近古典MVC的東西，你可以爲網絡做。後者具有非常有趣的用例，並解決了可重用性問題（並且在分佈式系統中也有一些潛力）。

現在是主要問題。

您從數據訪問邏輯分離領域的業務邏輯（域對象）（在datamappers），因爲您將獲得以下功能：

• 代碼脫鉤，關注點分離
• 能力單元測試獨立地

基本上，這可以讓你有代碼庫，其中添加一個特定的變化（如添加緩存或模型級授權檢查）不需要你重寫整個代碼庫。

此外，存儲機制本身變得更加靈活。您可以輕鬆更改特定域對象的數據存儲位置。例如，您可以將用戶詳細信息和身份驗證移至noSQL數據庫。這不會對您的業務邏輯的運作產生任何影響。當你在較大的團隊中工作或維護舊代碼時，這成爲一個關鍵問題，因爲很難掌握整個系統並保持這些知識是最新的。

至於數據訪問層做什麼：它需要域對象（包含域業務邏輯的東西），並存儲來自它們的數據或爲數據源層檢索信息。

另外，我建議研究/手錶：

• SOLID principles
• Unit testing（我會建議看全部來自清潔守則會談講座）

_{免責聲明：我的主要語言是PHP，並且只在web上下文中具有MVC相關模式的經驗（主要與它的Model2變體，因爲Web本身的明顯限制），它已經塑造了MVC結構的my understanding。}

Answer 2

MVC和其他人被認爲是用戶界面/表示模式，因爲他們的主要任務是接受來自外部源的請求並顯示結果。這些模式的M部分通常是指用作幫助填充視圖（也稱爲視圖模型）的DTO（數據傳輸對象）的簡單模型。

業務邏輯，如果它比只是CRUD操作更強烈，通常與此分開。這允許不同類型的前端應用程序（這裏是一個MVC網站，一個實際的手機/平板電腦應用程序）以不同方式與數據進行交互。

換句話說，MVC和類似的東西實際上只是真正做東西的商業邏輯之上的皮膚。

您需要問問自己，將EF部分與項目其餘部分分開是否合理。如果你對數據做的不僅僅是CRUD操作，我會說是。

Answer 3

您不明確需要單獨的DAL，因爲EF是您的數據訪問層和模型在同一時間。如果你是我們POCO的模型，你需要一個圖層來處理這些對象的持久性。所以如果你使用NH作爲OR/M，那麼你的模型只包含POCO對象而NH是你的DAL。 NH通常隱藏在一個單獨的層中，但這並不是必須的。如果涉及GUI，則不會直接使用您的實體進行綁定等。MVVM爲其引入了ViewModel，它用作GUI和Domain Model之間的層，並提供模型中所需的所有數據GUI。