asp.net-mvc - ASP.NET MVC 5、Identity、Unity 容器解决方案架构

Question

假设一个由 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 --> 契约(Contract)(IAccountService)

其中 --> 是项目引用

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

Answer 1

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

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

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

where should the interfaces be defined?

Where should I put automapper code?

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

[...] I have a typical structure like this:

• 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 ，吉米解释说:

I used to care quite a bit about project structure in applications. Trying to enforce logical layering through physical projects, I would start off a project by defaulting to building an app with at least two projects, if not more.

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

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



尽管吉米确实通过说:

I have absolutely nothing against layered software design. Using project structure to do so is a waste of time if you only have 1 app you're deploying [...]

(强调我的)

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

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

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

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