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

Question

啟動MVC項目時出現設計問題。 我遵循的示例位於以下鏈接上： 實施存儲庫和工作單元模式

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（保持簡單，愚蠢）之類的原則將引導您前進。 剩下的就是分析（需求收集的實踐）和在該領域的多年經驗。 兩者都不可以教，但要求您繼續練習。