Age*_*rum 6 architecture tdd design-patterns dependency-injection
我一直在阅读关于依赖注入的内容,我理解一个方法应该从调用者那里获得它所需要的基本概念,而不是自己创建这样的项目.结果,new操作员几乎完全被从方法中删除了(当然,某些基本对象是免除的 - 我发现的一个例子是像StringBuilders这样的事情看起来像是疯了似乎必须传入).
我的问题听起来似乎很简单,但我怀疑答案实际上相当复杂:所有new运营商都去哪儿了？
答案似乎很简单:new操作符只是被推送到调用需要该对象的方法的方法.然而,问题在于,调用方法很可能也在测试中,因此new从调用方法推送到调用方法,直到最终到达root方法(此时似乎疯狂不可测试)会产生一个淫秽在调用堆栈中的各个点处使用的对象数量.当您认为根方法是各种其他方法的根时,情况变得更加复杂,因此需要为每种可能性创建对象.这也会产生一个性能问题,因为很快就会留下大量从未实际使用过的对象,但必须以"万一"方式实例化.
对我来说很明显,我错过了一些重要的知识,这对其他开发人员来说是如此明显,没有人想在博客文章中描述它.但是,我显然不知道我不知道的是什么,所以我谦卑地问我是否被允许进入这个秘密:所有的new经营者都去了哪里？
我应该提一下,我正在使用PHP进行开发,因此每个请求都在同一点开始,似乎根"方法" index.php需要涵盖应用程序可以执行的所有操作,以确保它为所有内容提供对象它会在当前请求做.再次,这里有一个根本的误解,我真的很想纠正它.
你几乎把它弄好了:它们最终都在你的作文根中.看看接近底部的Mark Seeman的采访,解释为什么这是一个好的做法并且很重要.
另外值得注意的是:依赖注入是指服务,而不是实体或值对象.因此,例如注射IUserRepository是有意义的,但IUser不是那么多 - 当然不是StringBuilder.根据你对更原始类型的括号,这可能有助于澄清事物:划分并不是真正的原始,而是它们在系统中的作用.
依赖注入通常用在 MVC 应用程序中。在这种情况下，“ new”，正如您所说的，通常进入控制器层。
Controler在调用Model时，实例化依赖关系，并将其交给Model，然后调用Model暴露的业务方法。
但不要以为 DI 就是“去掉 s new”。这是关于脱钩的。实例化（并因此“了解”）其他类的类越少，这些其他类的更改所造成的损害就越小。
另一个目标是让测试变得更容易。如果您有一种需要撰写和发送邮件的方法，则很难测试邮件是否正确撰写。但是，如果您删除实际发送邮件的依赖项，从此类到另一个类，并且仅提供一个可以向此方法发送邮件的对象，那么当您编写测试时，而不是为该方法提供一个可以发送邮件的对象，真的发送邮件，你将给这个方法一个仅假发送邮件的对象。你明白重点了吗？