具有 MVC4 EF 和存储库模式的 N 层架构

Question

我正在使用具有多层的 MVC 和 EF 创建示例 Web 应用程序。我还在使用存储库模式进行数据库访问。我只是

层是

1. 学生业务

   • 调用存储库并执行业务逻辑。

2. 学生资料

   • 实体 POCO
   • 实体上下文
   • 实体存储库

3. 学生对象

   • 包含域对象
4. MVC 网络应用程序
   • 实体控制器（在此处实例化服务之后）
   • 使用 NInject 绑定所有接口（此项目包含对所有其他层的引用）。

我需要帮助来了解这个设计的优缺点。

Answer 1

除了广告。和不利。 (http://www.codeproject.com/Articles/430014/N-Tier-Architecture-and-Tips#nAdvantages) 是为 N 层定义的，我将根据我最近使用类似架构的经验来介绍几点：

好处是：

• 由于控制器是薄层的并且业务逻辑存储在实际服务中，您可以共享服务项目用于不同的目的，例如 Windows 桌面等。您将来也可以为 Webapi 公开相同的服务。因此可重用性很高。

  • 每一层都在做自己的专门工作，在 NInject 的帮助下，您可以轻松地交换它们。我在当前项目中有一个很好的例子，在调试模式下，我使用 Exchange Online 服务作为邮件网关。而对于 Release，我必须使用 SMTP 服务作为邮件网关。 （请单独查看 DI adv. 的缺点）。

• 当您关注 NInject 接口时，您可以将 Mocks 用于 TDD。因此，您可以在列表中添加 TDD 和 DI 优势。

• Code First 是表示数据库的好方法，它是干净透明的方法。你知道发生了什么。

• 通过代码优先的数据库版本控制是最大的卖点。

缺点：

• 即使您在逻辑上分离了这些组件，但您不能单独部署这些组件。因此，可以通过适当的会话处理来实现缩放。因此需要更多的工作。

• CS 文件太多，每个控制器（1 个或 2 个）、服务（1 个接口和 1 个类）、存储库（1 个接口、1 个类）一个。因此，根据您的应用程序，它将广泛增长。我已经有 100 多个文件要管理。但是在 Resharper 的帮助下，您可以摆脱这个缺点并将其转化为您自己的好处。

• 即使您可以为存储库、控制器和服务编写通用 CRUD 操作。总有一天，您最终会走上让每个控制器拥有自己的服务等等的道路......

  • 我发现验证无处不在，但我认为任何 N 层都是如此。

• 如果您首先使用带有代码的 POCO，那么您肯定需要非常了解迁移；我仍在努力寻找许多答案。

• 对于代码优先的 DbContext，没有直接且简单的方法来调用函数（如导入函数、数据库优先的 sp - edmx）。它很干净，但可能需要很多 hack。

• Like Code 首先为您创建数据库，因此数据库管理不需要版本控制。但是，我发现处理部署、视图、函数、sp 很复杂；需要编码。

• 在性能方面，我想这取决于你如何编写代码。

总的来说，我的 Webapi 遵循完全相同的架构，我对这个架构非常满意。