问ASP.NET MVC 5、身份、统一容器解决方案体系结构

EN

是的，将您的解决方案分成更小的项目，如MVC、Identity和IoC.是安全的。

至少，这是我的简短回答。

，这有道理吗？，很长的答案有点复杂。在此之前，我已经回答了一些类似的问题，包括解决方案和项目架构：

• 应该在哪里定义接口？
• 我应该把自动代码放在哪里？

在上面的回答中，我解释了

..。我有这样一个典型的结构：

• MyProject.Core
• MyProject.Domain
• MyProject.DependencyInjection
• MyProject.Infrastructure
• MyProject.Web
• MyProject.Tests

杰弗里·巴勒莫鼓励使用洋葱建筑。在关于洋葱建筑的文章的第4部分中，Jeffrey提供了具有以下结构的示例解

• 核心
• 基础设施
• IntegrationTests
• 用户界面
• UnitTests

然而，吉米·博加德有点不同意我和我的方法。

在演化项目结构中，吉米解释道：

我过去非常关心应用程序中的项目结构。试图通过物理项目执行逻辑分层，我会从默认构建至少两个项目(如果不是更多)的应用程序开始一个项目。

实际上，Jimmy将他以前喜欢的解决方案体系结构风格描述为类似于我前面提到的风格。

吉米进一步说，“决定项目结构是浪费时间和精力”。他实际上更喜欢更简单的解决方案结构。也就是说，非常小的。

​

​

虽然吉米确实澄清了他的立场，但他说：

我绝对不反对分层软件设计。使用项目结构这样做是浪费时间，如果您只有1应用程序，您正在部署.

(强调地雷)

如果您有其他应用程序需要引用MVC解决方案的各个方面，那么将它们拆分到他们自己的项目中是非常有意义的，这样您就可以很容易地引用它们。

我认为我们应该得出结论：

解决方案体系结构不是一条规则或法律。将项目分离出有意义的地方。

确保您的解决方案易于维护，并且易于被其他人理解。不要让你的解决方案过于复杂。

我将把我的0.02分加到罗文的最佳答案上。我将介绍更多关于实际身份实现的内容。

就ASP.Net身份框架而言，将其从MVC项目移到更高(或更低，取决于您如何放置它)层可能有点棘手。我很确定您希望域层中有ApplicationUser对象。但是ApplicationUser依赖于IdentityUser，这依赖于Identity.EntityFramework，依赖于EntityFramework。并且将EF添加到您的域项目中可能会稍微违背洋葱架构的规则。

此外，来自身份框架的ApplicationUserManager也是庞大的(就方法的数量而言)，并且还依赖于EF。因此，将其隐藏在接口后面是很棘手的。

所以你真的有两个选择：

1. 将EF添加到您的域项目中，并在域层中包含ApplicationUser和ApplicationUserManager类。而且，由于多种原因，不要将UserManager封装在接口中。
2. 以不同的方式进行一次攻击，将所有的身份信息留在您的MVC层中，确定您需要从域层执行的非常小的操作集，并在ApplicationUserManager之上添加一个很小的接口。

我在不同的项目中尝试过这两种方法，两种方法效果都很好。我尝试在ApplicationUserManager之上添加接口，但失败了--主要是因为类的大小，而且它的目标是以异步方式工作，还有同步包装。同步包装将不能与您的界面工作-因为强输入。

我编写了一个博客-关于将DI应用于身份框架的文章，还有一个关于分层分离的评论中的讨论 --请看一下想法。