使用工作單元和存儲庫模式的3層MVC應用程序

Question

我在啓動我的MVC項目時遇到了設計問題。我所遵循的例子是以下鏈接：Implementing the Repository and Unit of Work Patterns

1：http://www.asp.net/mvc/tutorials/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application。

在那裏，工作單元和通用資源庫位於數據層項目中。在我的項目中，他們也在那裏，但是從我看到的他們正在從工作單元課堂直接進入控制器的實例中。

因爲我做了BAL項目，我很感興趣，我將不得不改變目前的設計，BAL項目應該包含什麼（一些小代碼將會有很大幫助）。

這是我目前項目的截圖。

Answer 1

的BAL應該包含業務邏輯。

控制器將使用在橋模式BAL的API和高層次的功能和協調數據交換與下面的DAL，加載和持久化數據，如：

MyEntity e; 
Repository<MyEntity> r; 

r = DAL.GetRepository<MyEntity>; 
e = r.Retrieve(x => x.Age > 20); 
v = BAL.GetValidator<MyEntity>(); 

e.Broken = !v.Validate(e).HasErrors; 
e.LastChecked = DateTime.Now; 
DAL.GetRepository("MyEntity").Update(e); 

這不是工作的代碼，它只是給出了一個薄控制器的想法。如果這種情況經常重複（比如3次或更多），現在是考慮將代碼推廣到BAL的時候了，因爲它可能是公認的商業程序。

您可以根據需要添加工作單元模式和using() {}子句。問題始終是：什麼是業務邏輯，是應用程序邏輯？什麼進入控制器和什麼進入圖書館？

一般情況下，儘量保持控制器精簡併保持BAL免於持久性邏輯和應用程序邏輯。

像DRY（不要重複自己）和KISS（保持簡單，愚蠢）的原則將引導你一路走來。剩下的就是分析（收集需求的做法）以及該領域多年的經驗。兩者都不能教，但要求你繼續練習。