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

至少,这是我的简短回答.

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

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

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

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

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