Asp.net mvc 4 具有MVC4 EF和存储库模式的N层体系结构

我正在创建带有MVC和EF的多层次web应用示例。我还使用存储库模式访问数据库。我只是

层是

学生业务

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

学生数据

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

学生物品

• 包含域对象

MVC Web应用程序

• 实体控制器（在此处实例化服务后）
• 使用NInject am绑定所有接口（此项目包含对所有其他层的引用）

---

除了adv.和disadv.之外，我还需要帮助了解这个设计的优缺点。

。（）是为N-tier定义的。根据我最近使用类似体系结构的经验，我将介绍几点：

好处是：

• 由于控制器是薄层的，业务逻辑存储在实际的服务中，因此您可以为不同的目的（如Windows桌面等）共享服务项目。。将来还可以为Webapi公开相同的服务。因此可重用性很高
  • 每一层都在做自己的工作，在NInject的帮助下，您可以轻松地交换相同的内容。在我当前的项目中，我有一个很好的例子，在调试模式中，我使用Exchange Online services for mail gateway。而对于发行版，我必须使用SMTP服务作为邮件网关。（请单独检查DI adv.缺点）
• 当您遵循NInject的接口时，您可以将Mock用于TDD。因此，您可以在列表中添加TDD和DI福利

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

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

缺点：

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

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

• 即使您可以为存储库、控制器以及服务编写通用CRUD操作。总有一天，你会走上让每个控制器都有自己的服务的道路，等等
  • 我发现验证将无处不在，但我认为任何N层都是如此
• 如果您首先在代码中使用POCO，那么您肯定需要非常好地理解迁移；我仍在努力寻找许多答案

• 对于代码优先的DbContext，没有直接而简单的方法来调用函数（就像导入函数一样，首先是数据库中的sp-edmx）。这是干净的，但有很多黑客可能需要

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

• 就性能而言，我想这将取决于您如何编写代码

总的来说，我的Webapi遵循完全相同的体系结构，我对这种体系结构非常满意