假设一个由 ASP.NET MVC 5 和 OWIN/Identity 成员组成的 Web 项目。 IoC 是用 Unity 完成的。现在一切都在一个项目中。 问题：将 MVC、Idenity 和 IoC 分离到孤立的项目中，并将 Identity 封装到一些 IAccountService 中，以便在 MVC 项目中由 Unity 解析，是否有意义？ 这个问题似乎很傻，但我的橡皮鸭不知什么原因一直保持沉默，你猜？
我想要达到的目标是这样的
ASP.NET MVC (OWIN) --> IoC (Unity) --> AccountServiceImpl --> Identity
MVC、IoC --> 合同（IAccountService）
其中 --> 是项目参考
我需要它能够更改 IoC 容器，还需要通过接口从其他项目访问身份数据
【问题讨论】：
标签： asp.net-mvc asp.net-identity-2
是的，将您的解决方案分成较小的项目（例如 MVC、Identity 和 IoC）是安全的。
至少，这是我的简短回答。
有意义吗？ 长答案有点复杂。在解决解决方案和项目架构之前，我已经回答了一些类似的问题：
在上面的答案中，我解释了
[...] 我有一个这样的典型结构：
- MyProject.Core
- MyProject.Domain
- MyProject.DependencyInjection
- MyProject.Infrastructure
- MyProject.Web
- MyProject.Tests
Jeffrey Palermo 鼓励使用Onion Architecture。在part 4 of his article on Onion Architecture 中，Jeffrey 提供了一个具有以下结构的example solution
然而，Jimmy Bogard有点不同意我和我的方法。
在Evolutionary Project Structure，Jimmy 解释说：
我曾经非常关心应用程序中的项目结构。尝试通过物理项目强制执行逻辑分层，我会默认构建一个包含至少两个项目（如果不是更多）的应用程序来启动一个项目。
事实上，Jimmy 将他之前喜欢的解决方案架构风格描述为与我上面提到的风格相似。
Jimmy 进一步说“决定项目结构是浪费时间和精力”。他实际上更喜欢更简单的解决方案结构。也就是说，很少。
尽管 Jimmy 确实通过以下方式阐明了自己的立场：
我完全不反对分层软件设计。如果您只有要部署的应用程序 [...]
，使用项目结构这样做是浪费时间
（强调我的）
如果您有其他应用程序需要引用您的 MVC 解决方案的各个方面，那么将它们拆分到自己的项目中以便您可以轻松引用它们可能非常有意义。
我认为我们应该得出的结论是：
解决方案架构不是规则或法律。在有意义的地方分离项目。
确保您的解决方案易于维护且易于被他人理解。不要让您的解决方案过于复杂。
【讨论】：
我将把 0.02 美分加到 Rowan 的出色回答中。我将详细介绍实际的身份实现。
就 ASP.Net 身份框架而言 - 将其从 MVC 项目移到更高（或更低，取决于你如何放置它）的坐席层可能有点棘手。我很确定您希望在您的域层中有ApplicationUser 对象。但是ApplicationUser 依赖于IdentityUser，而Identity.EntityFramework 又依赖于EntityFramework。并且将 EF 添加到您的域项目可能会稍微违反 Onion Architecture 的规则。
另外，来自 Identity 框架的 ApplicationUserManager 非常庞大（就方法的数量而言）并且还依赖于 EF。因此将其隐藏在界面后面可能会很棘手。
所以你真的有两个选择：
ApplicationUser 和 ApplicationUserManager 类。并且不要出于多种原因将UserManager 包装在界面中。ApplicationUserManager 之上添加一个小接口。我在不同的项目中都尝试了这两种方法，并且都同样有效。我曾尝试在ApplicationUserManager 之上添加接口，但失败了——主要是因为类的大小，它还旨在以异步方式工作并且有同步包装器。同步包装器不适用于您的界面 - 因为强类型。
我写了一个blog-post about applying DI to Identity framework 并且有一个关于层分离的discussion in the comments - 看看想法。
【讨论】：