使用工作单元和存储库模式的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应包含业务逻辑。

Controller将以桥接模式使用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（保持简单，愚蠢）等原则将引导您一路走来。其余的是分析（需求收集的实践）和该领域多年的经验。两者都不能教，但要求你继续练习。