我最近从使用Ninject在ASP.Net MVC中进行依赖注入的团队变成了一个除了ASP.Net 2.0中引入的提供者模型模式之外对IoC解决方案一无所知的团队.
我试图找到一个良好的工作流程来处理提供者模型,但每次我真正得到编码,它主要感觉就像模式正在阻碍我感到分心,整理配置陷阱和cobbling copypasta静态外观当我可以完成工作时.
现在我正在开始一个小型的ASP.Net MVC绿地项目,并发现一些团队成员对采用DI框架的阻力.
我知道DI框架比编写提供者模型更快更容易,但每次我试图阐明原因时都会陷入细节.
解决方法
Provider idiom is,at best,a design smell.最好完全避免它.
另一方面,依赖注入只是the most efficient way to enable loose coupling.如果你想编写可维护的代码,它是实现这一目标的最有效方法之一.
然而,大多数人倾向于抵制DI,因为它“感觉”倒退,但它确实是一个人们需要克服的东西.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
