通过ASP.NET MVC 5和OWIN / Identity成员身份来假定一个Web项目。IoC是使用Unity完成的。现在一切都在一个项目内。问题:将MVC,Idenity和IoC分离到隔离的项目,并将Identity封装到某些IAccountService中,由Unity在MVC项目中解决是否有意义?这个问题似乎很愚蠢,但是我的橡皮鸭出于未知的原因保持沉默,有什么猜想吗?
我想要达到的目标是这样的
ASP.NET MVC(OWIN)-> IoC(统一)-> AccountServiceImpl->身份
MVC和IoC都->合同(IAccountService)
->是项目参考
我需要它能够更改IoC容器,还需要通过接口从另一个项目访问身份数据
是的,将您的解决方案分成较小的项目(例如MVC,Identity和IoC)是安全的。
至少,这是我的简短答案。
是否有意义?长答案有点复杂。在解决解决方案和项目体系结构之前,我已经回答了一些类似的问题:
在上面的答案中,我解释了
[...]我有一个像这样的典型结构:
- MyProject.Core
- MyProject.Domain
- MyProject.DependencyInjection
- MyProject.Infrastructure
- MyProject.Web
- MyProject.Tests
Jeffrey Palermo鼓励使用Onion Architecture。在有关Onion Architecture的文章的第4部分中,Jeffrey提供了具有以下结构的示例解决方案
但是,吉米·博加德 (Jimmy Bogard)有点不同意我和我的做法。
吉米(Jimmy)在“演化项目结构”中解释:
我曾经非常关心应用程序中的项目结构。尝试通过物理项目强制执行逻辑分层,我会从一个项目开始,默认情况下是使用至少两个(如果不是更多)项目构建一个应用程序。
确实,Jimmy将他先前首选的解决方案体系结构样式描述为类似于我上面提到的样式。
吉米进一步说,“确定项目结构是浪费时间和精力”。他实际上更喜欢简单的解决方案结构。也就是说,很少。
尽管吉米的确通过以下方式澄清了自己的立场:
我绝对不反对分层软件设计。如果您只有1个要部署的应用程序,则使用项目结构这样做会浪费时间[...]
(强调我的)
如果您还有其他应用程序需要引用您的MVC解决方案的各个方面,则将它们拆分成各自的项目可能很有意义,以便您可以轻松地引用它们。
我认为我们应该得出的结论是:
解决方案体系结构不是规则或法律。分开进行有意义的项目。
确保您的解决方案易于维护并且易于他人理解。不要使您的解决方案过于复杂。
本文收集自互联网,转载请注明来源。
如有侵权,请联系[email protected] 删除。
我来说两句