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

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

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

ASP.NET MVC(OWIN) – > IoC(Unity) – > AccountServiceImpl – >身分

MVC,IoC – >合同(IAccountService)

哪里 – >是一个项目参考

我需要它能够更改IoC容器,我还需要通过接口从另一个项目访问身份数据

解决方法

是的,将您的解决方案分成较小的项目(如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

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

但是,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将他以前首选的解决方案架构风格描述为类似于我上面提到的风格.

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

虽然吉米说明了他的立场：

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解决方案的各个方面,将它们分成自己的项目可能很有意义,以便您可以轻松地引用它们.

我想我们应该得出的结论是：

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

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