使用工作单元和存储库模式的 3 层 MVC 应用程序答案

【问题标题】：3-tier MVC application using Unit of Work and Repository pattern使用工作单元和存储库模式的 3 层 MVC 应用程序
【发布时间】：2014-01-26 15:16:56
【问题描述】：

我在启动 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 项目应该包含哪些内容（一些小代码会有很大帮助）。

这是我当前项目的截图。

【问题讨论】：

我的回答对您有任何帮助吗？

标签： c# .net entity-framework repository-pattern unit-of-work

【解决方案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（保持简单，愚蠢）等原则将指导您前进。剩下的就是分析（需求收集实践）和该领域多年的经验。两者都不能教，但需要你不断练习。

【讨论】：