具有MVC4 EF和存储库模式的N层体系结构

Question

我正在创建具有多层MVC和EF的示例Web应用程序。我也使用Repository Pattern进行数据库访问。我只是

图层是

1. 学生生意

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

2. 学生资料

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

3. 学生对象

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

我需要帮助这个设计的优点和缺点。

Answer 1

除了adv。和disadv。 （http://www.codeproject.com/Articles/430014/N-Tier-Architecture-and-Tips#nAdvantages）是针对N层定义的，我将根据我最近在类似架构方面的经验介绍几点：

好处是：

• 由于控制器是精简分层的，Business Logics存储在Actual Services中，因此您可以为不同的目的共享服务项目，例如Windows桌面等。您还可以在将来为Webapi公开相同的服务。因此，可用性很高。

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

• 当您关注NInject的接口时，可以使用Mocks进行TDD。因此，您可以在列表中添加TDD和DI优惠。

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

• 首先通过Code实现数据库版本控制是最大的卖点。

缺点：

• 即使您在逻辑上将这些组件分开，但也无法单独部署这些组件。因此，可以通过适当的会话处理来实现缩放。因此工作量更大。

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

• 即使你可以为Repository，Controller和Services编写通用CRUD操作。有一段时间你最终会走上让每个控制器拥有自己的服务的道路等等......

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

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

• 对于Code first DbContext，没有直接和简单的方法来调用函数（比如你导入函数，sp在Database first-edmx中）。它很干净，但可能需要很多黑客。

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

• 就性能而言，我想这将归结为您编写代码的方式。

总的来说，我对Webapi采用完全相同的架构，我对这种架构非常满意。