4

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

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

达尔

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

提单

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

网络

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

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

有什么建议吗？

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

4

1 回答 1

5

你可以使用这个 和这篇文章。

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

应用。这样的架构师可以利用他们的经验来加速这个过程。由于我之前做过类似的 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 概念和设计模式等。
使您的设计保持一致。在所有模块和层中遵循相同的标准。这包括简化概念（例如，如果您在两个不同的模块中使用了两种不同的设计模式来实现相同的目标，那么选择更好的方法并在两个地方都使用），以及项目中使用的约定。调整设计是该过程的最后一部分。为此，您需要与项目团队开会。在那次会议上，您需要向您的团队展示您的设计并让他们提出问题。以此为契机，诚实地评估/调整您的设计。

于 2013-02-07T07:12:13.763 回答