asp.net-mvc – 使用依赖注入来组织ASP.Net MVC解决方案的最佳方式是什么?

前端之家收集整理的这篇文章主要介绍了asp.net-mvc – 使用依赖注入来组织ASP.Net MVC解决方案的最佳方式是什么?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我早期开发了一个新的ASP.Net MVC项目,我使用这个项目进入DI.我很确定我要去结构图,但这不是我所问的.我想要弄清楚的是如何最好地组织我的解决方案.单元测试项目和模型都要获取一个配置文件来映射它们的依赖关系,还是有一个类来统统呢?

另外,有没有任何新手陷阱,以避免我太过分了呢?

许多谢谢,所有…..

更新
我应该补充说,当我说“组织解决方案”时,我不是指文件/文件夹等的数量,而是如何构造与DI有关的类.特别是如何管理引导程序.我可以看到我的那些不好的措辞可能会导致混乱.

解决方法

鼓励更好的TDD.有两个测试项目和/或namespeaces X.Unit.Tests& X.Integrations.Tests.

我在我的主项目中有一个“代码名称空间目录”(/ Config)中的DI代码,但是在我的集成代码测试中,我可能只需要调用这些注册表,或者在我的基础设备或设置中需要覆盖.

例如.

/Config/ServiceRegistry.cs
/Config/RepositoryRegistry.cs
/Config/Bootstrapper.cs

在global.asax中,我调用Bootstrapper.Init(),这将调用x.AddRegistry(新的ServiceRegistry())等等.

在我的单元测试中,您不需要在集成测试中使用DI.在我的IntegrationTests例如如果我正在测试NHibernate到数据库,我可以用TestSetUp中的RepositoryRegistry初始化SM,并使用一个仅包含GetInstance()的帮助方法.

我不分解到项目.Bootstraper和.Domain,直到我绝对必须…三个项目,X,X.UnitTests,X.Integration如果你需要更多的移动.我来自一个背景/公司执行有几十个项目,它觉得肮脏的第一次减少但不是现在,我快速成长运行,如果需要,重新组织解决方案结构.

猜你在找的asp.Net相关文章