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

除了adv。和不满意。（http://www.codeproject.com/Articles/430014/N-Tier-Architecture-and-Tips#nAdvantages）是为N层定义的。根据我最近对类似体系结构的经验，我将介绍几个要点：

好处是：

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

  • 每个图层都在做自己的专属工作，并且在NInject的帮助下，您可以轻松地交换相同的内容。我在当前项目中有一个很好的例子，在该例子中，对于调试模式，我将Exchange Online服务用于邮件网关。而对于发行版，我必须使用SMTP服务作为邮件网关。（请单独检查DI ad。的缺点）。

• 当您遵循用于NInject的接口时，可以将Mocks用于TDD。因此，您可以在列表中添加TDD和DI权益。

• Code First是代表您的数据库的一种很好的方法，它是一种干净透明的方法。你知道发生了什么事。

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

缺点：

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

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

• 即使您可能为存储库，控制器以及服务编写了通用CRUD操作。有时候，您最终会走上使每个控制器拥有自己的服务之类的道路……

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

• 如果您首先将POCO与Code一起使用，那么绝对需要非常了解迁移。我仍在努力寻找许多答案。

• 对于代码优先DbContext，没有直接，简单的方法来调用函数（就像您导入函数一样，在Database first-edmx中）。很干净，但是可能需要很多技巧。

• 就像Code会先为您创建数据库一样，因此数据库管理不需要版本控制。但是，我发现处理部署，视图，功能等等很复杂。需要编码。

• 在性能方面，我认为这将取决于您编写代码的方式。

总体而言，我遵循的Webapi架构完全相同，对此架构我感到非常满意。