ASP.NET MVC4 n 层架构：最佳方法

Question

我为 MVC4 webapp + EntityFramwork5 开发了一个 3 层架构。 我想保持单独的层，所以只有 DAL 知道我正在使用 EF，例如。

实际上我有很多课程要管理：

DAL

1. 实体 POCO
2. 实体数据上下文：DbContext
3. 实体存储库

BL

1. 实体视图模型
2. 实体服务（实例化实体存储库）

网络

1. 实体控制器（实例化实体服务）

这是有效的，但很难维护。我正在考虑删除 DAL 中的实体存储库并直接使用 DataContext（如果我没记错的话，毕竟 DbContext 已被设计为存储库和工作单元），但这将迫使我添加对我的 BL 中的 EntityFramework.dll。不是什么大问题，但我不确定它是否是最佳选择。

有什么建议吗？

（希望我提供了足够的信息，如果您需要更多信息，请询问）

Answer 1

您可以使用this this 和this 文章。

An experienced Architect does not need to go through every single step in the book to get a reasonable design done for a small web

应用程序。这样的架构师可以利用他们的经验来加速 过程。因为我之前做过类似的网络应用程序并且有 了解我的可交付成果，我将采取更快的方法 完成我们 DMS 设计的初始部分。这将有望 帮我缩短这篇文章的长度。

For those who do not have experience, let me briefly mention the general steps that involved in architecturing a software below...

Understand the initial customer requirement - Ask questions and do research to further elaborate the requirement
Define the process flow of the system preferably in visual (diagram) form. I usually draw a process-flow diagram here. In my

努力，我会先尝试定义系统的手动版本 然后会尝试将其转换为自动化版本，同时 识别过程及其关系。该工艺流程 我们在这里绘制的图表可以用作验证 与客户一起捕捉需求。 确定适合您要求的软件开发模型 在设计开始之前完全捕获和定义需求后，您可以使用“瀑布”模型。但是当 需求未定义，可以使用“Spiral”的变体来处理 接着就，随即。 当需求没有定义时，系统在设计时就被定义了。在这种情况下，您需要保留足够的空间 在各自的模块中，预计以后的扩展。 决定使用什么架构。就我而言，为了设计我们的文档管理系统 (DMS)，我将使用以下组合 ASP.NET MVC 和多层体系结构（三层变体）。 分析系统并确定其模块或子系统。
一次选择一个子系统，然后对其进行进一步分析，并确定属于该系统部分的所有粒度级别的需求。 识别数据实体并定义实体之间的关系（实体关系图或 ER 图）。这样可以 其次是识别业务实体（一些业务实体 直接映射到系统的类）并定义业务 工艺流程。 组织你的实体。这是您规范数据库的地方，并决定要使用的 OOP 概念和设计模式 等等
使您的设计保持一致。在所有模块和层中遵循相同的标准。这包括简化概念（作为 例如，如果您在两个项目中使用了两种不同的设计模式 不同的模块达到相同的目标，然后选择更好的 方法并在这两个地方使用它），以及在 项目。 调整设计是该过程的最后一部分。为此，您需要与项目团队开会。在那里面 会议您需要向您的团队展示您的设计并让他们询问 关于它的问题。以此为契机，诚实评估/ 调整你的设计。