ASP.NET MVC 5，Identity，Unity容器解决方案体系结构

Question

假设ASP.NET MVC 5和OWIN / Identity成员资格的Web项目。 IoC完成了Unity。现在一切都在一个项目内。 问题：将MVC，Idenity和IoC分离到隔离项目并将Identity封装到某些IAccountService中以便Unity在MVC项目中解析是否有意义？ 这个问题似乎很愚蠢，但我的橡皮鸭因为不明原因保持沉默，有什么猜测吗？

我想要实现的目标看起来像这样

ASP.NET MVC（OWIN） - ＆gt; IoC（Unity） - ＆gt; AccountServiceImpl - ＆gt;身份

MVC，IoC - ＆gt;合同（IAccountService）

其中 - ＆gt;是项目参考

我需要它能够更改IoC容器，我还需要通过接口从其他项目访问身份数据

Answer 1

是的，将您的解决方案分成较小的项目（如MVC，Identity和IoC）是安全的。

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

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

• where should the interfaces be defined?
• Where should I put automapper code?

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

  

[...]我有一个典型的结构：

     

  
• 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以下结构

• 核心
• 基础设施
• IntegrationTests
• UI
• 单元测试

但是，Jimmy Bogard 有些不同意我和我的做法。

在Evolutionary Project Structure中，吉米解释道：

  

我曾经非常关心应用程序中的项目结构。试图通过物理项目强制执行逻辑分层，我会通过默认构建至少包含两个项目的应用程序来启动项目，如果不是更多的话。

事实上，Jimmy将他以前首选的解决方案架构风格描述为与我上面提到的风格类似。

Jimmy进一步说，＆＃34;决定项目结构是浪费时间和精力＆＃34; 。他实际上更喜欢更简单的解决方案结构。也就是说，很少。

虽然吉米通过说：

来澄清他的立场

  

我绝对没有反对分层软件设计。如果您只有 1个应用程序正在部署 [...]

，那么使用项目结构这样做是浪费时间

（强调我的）

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

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

解决方案架构不是规则或法律。在有意义的地方分开项目。

确保您的解决方案易于维护并易于被他人理解。不要使解决方案过于复杂。

Answer 2

我会将我的0.02美分加到Rowan的优秀答案中。我将详细介绍实际的身份实现。

就ASP.Net Identity框架而言 - 将它从MVC项目中移出更高（或更低，取决于你如何放置）坐垫层可能有点棘手。我很确定你想在你的域层中拥有ApplicationUser个对象。但ApplicationUser取决于IdentityUser，Identity.EntityFramework取决于EntityFramework，具体取决于ApplicationUserManager。将EF添加到您的域项目可能会略微违反洋葱架构的规则。

来自Identity框架的ApplicationUser也很大（就方法数量而言）并且还取决于EF。所以将它隐藏在界面后面可能会很棘手。

所以你真的有两个选择：

1. 点击并将EF添加到您的域项目中，并在您的域层中添加ApplicationUserManager和UserManager个类。并且由于多种原因，不要将ApplicationUserManager包装在接口中。
2. 以不同的方式点击并将所有Identity内容保留在MVC层中，确定您需要从Domain层执行的一小部分操作，并在ApplicationUserManager之上添加一个微小的界面。

我在不同的项目中尝试了这两种方法，并且两种方法都同样有效。我尝试在{{1}}之上添加接口并且失败 - 主要是因为类的大小，它也旨在以异步方式工作并且有sync-wrappers。同步包装器不适用于您的界面 - 因为强类型。

我写了一个blog-post about applying DI to Identity framework，并且有一个discussion in the comments关于图层分离 - 寻找想法。