使用工作单元和存储库模式的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（保持简单，愚蠢）之类的原则将引导您前进。 剩下的就是分析（需求收集的实践）和在该领域的多年经验。 两者都不可以教，但要求您继续练习。