使用工作单元和存储库模式的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（保持简单，愚蠢）的原则将引导你一路走来。剩下的就是分析（收集需求的做法）以及该领域多年的经验。两者都不能教，但要求你继续练习。