atitit.项目设计模式---ioc attilax总结v4 q11
2. IoC的实现模式di 与 service loctor4
3. Ioc实现的三种模式：构造函数注入，属性注入(推荐),接口注入4
3.2. Atitit.ioc容器的设计 lazy加载模式.doc4
5.3. 一种实用和优雅的来解决这些问题，是使用容器的依赖注入6
5.4. 使用 vm 注入,隐藏注入,golbal 变量..6
1. ioc的原理
1.1. .IOC的之前
我们知道在面向对象设计的软件系统中，它的底层都是由N个对象构成的，各个对象之间通过相互合作，最终实现系统地业务逻辑[1]。
图1 软件系统中耦合的对象
1.2. ioc后的实现
IOC理论提出的观点大体是这样的：借助于“第三方”实现具有依赖关系的对象之间的解耦。如下图：
图3 IOC解耦过程
大家看到了吧，由于引进了中间位置的“第三方”，也就是IOC容器，使得A、B、C、D这4个对象没有了耦合关
1.3. ioc的演化
不管是依赖注入，还是控制反转，都说明Spring采用动态、灵活的方式来管理各种对象。对象与对象之间的具体实现互相透明。在理解依赖注入之前，看如下这个问题在各种社会形态里如何解决:一个人(Java实例，调用者)需要一把斧子(Java实例，被调用者)。
(1)原始社会里，几乎没有社会分工。需要斧子的人(调用者)只能自己去磨一把斧子(被调用者)。对应的情形为:Java程序里的调用者自己创建被调用者。
(2)进入工业社会，工厂出现。斧子不再由普通人完成，而在工厂里被生产出来，此时需要斧子的人(调用者)找到工厂，购买斧子，无须关心斧子的制造过程。对应Java程序的简单工厂的设计模式。
(3)进入“按需分配”社会，需要斧子的人不需要找到工厂，坐在家里发出一个简单指令:需要斧子。斧子就自然出现在他面前。对应Spring的依赖注入。
第一种情况下，Java实例的调用者创建被调用的Java实例，必然要求被调用的Java类出现在调用者的代码里。无法实现二者之间的松耦合。
第二种情况下，调用者无须关心被调用者具体实现过程，只需要找到符合某种标准(接口)的实例，即可使用。此时调用的代码面向接口编程，可以让调用者和被调用者解耦，这也是工厂模式大量使用的原因。但调用者需要自己定位工厂，调用者与特定工厂耦合在一起。
第三种情况下，调用者无须自己定位工厂，程序运行到需要被调用者时，系统自动提供被调用者实例。事实上，调用者和被调用者都处于Spring的管理下，二者之间的依赖关系由Spring提供。
作者:: 老哇的爪子 Attilax 艾龙， EMAIL:1466519819@qq.com
转载请注明来源： http://blog.csdn.net/attilax
1.4. 依赖注入和控制反转是同一概念吗？
根据上面的讲述，应该能看出来，依赖注入和控制反转是对同一件事情的不同描述，从某个方面讲，就是它们描述的角度不同。依赖注入是从应用程序的角度在描 述，可以把依赖注入描述完整点：应用程序依赖容器创建并注入它所需要的外部资源；而控制反转是从容器的角度在描述，描述完整点：容器控制应用程序，由容器 反向的向应用程序注入应用程序所需要的外部资源。
2. IoC的实现模式di 与 service loctor
“依赖注入”（Dependency Injection），并将其与“服务定位器”（Service Locator）模式作一个比较。不过，这两者之间的差异并不太重要，更重要的是：应该将组件的配置与使用分离开——两个模式的目标都是这个。
Refer Atitit.ioc的实现模式 di servicelocator的区别与联系v2 paa
3. Ioc实现的三种模式：构造函数注入，属性注入(推荐),接口注入
接口注入
将调用类所有依赖注入的方法抽取到一个接口中，调用类通过实现该接口提供相应的注入方法。为了采取接口注入的方式
由于通过接口注入需要额外声明一个接口，增加了类的数目，而且它的效果和属性注入并无本质区别，因此我们不提倡采用这种方
3.1. 容器的依赖注入...注入容器(推荐)
3.2. Atitit.ioc容器的设计 lazy加载模式.doc
Map(k,obj)
K,delegate
4. 认识引入IOC框架的缺点，
做到心中有数，杜绝滥用框架[1]。
第一、软件系统中由于引入了第三方IOC容器，生成对象的步骤变得有些复杂，本来是两者之间的事情，又凭空多出一道手续，所以，我们在刚开始使用IOC框架的时候，会感觉系统变得不太直观。所以，引入了一个全新的框架，就会增加团队成员学习和认识的培训成本，并且在以后的运行维护中，还得让新加入者具备同样的知识体系。
第二、由于IOC容器生成对象是通过反射方式，在运行效率上有一定的损耗。如果你要追求运行效率的话，就必须对此进行权衡。
第三、具体到IOC框架产品(比如：Spring)来讲，需要进行大量的配制工作，比较繁琐，对于一些小的项目而言，客观上也可能加大一些工作成本。
第四、IOC框架产品本身的成熟度需要进行评估，如果引入一个不成熟的IOC框架产品，那么会影响到整个项目，所以这也是一个隐性的风险。
虽然实现了依赖注入，但是由于php本身是一种弱类型的语言，当类型发生变化时并不会报错，从而失去了ioc的精髓，因此有其形而无其神。
5. 自己实现ioc
5.1. ioc框架的实现原理map+容器法
理解PHP 依赖注入 Laravel IoC容器 - ◆gHOST◇的专栏 - 博客频道 - CSDN.NET.htm
将的是Phalcon 的ioc实现原理
5.2. 每个组件set法
1. $some = new SomeComponent();
2.
3. //Pass the connection defined in the registry
4. $some->setConnection(Registry::getConnection());
5.
6. $some->someDbTask();
1. $some->setConnection($connection);
2. $some->setSession($session);
3. $some->setFileSystem($fileSystem);
4. $some->setFilter($filter);
5. $some->setSelector($selector);
我想，我们不得不在应用程序的许多地方创建这个对象。如果你不需要依赖的组件后，我们又要去代码注入部分移除构造函数中的参数或者是setter方法。为了解决这个问题，我们再次返回去使用一个全局注册表来创建组件。但是，在创建对象之前，它增加了一个新的抽象层：
5.3. 一种实用和优雅的来解决这些问题，是使用容器的依赖注入
，像我们在前面看到的，容器作为全局注册表，使用容器的依赖注入做为一种桥梁来解决依赖可以使我们的代码耦合度更低，很好的降低了组件的复杂性：
1. //Pass the service container as unique parameter
2. $some = new SomeComponent($di);
3.
4. $some->someTask();
5.4. 使用 vm 注入,隐藏注入,golbal 变量..
通过include来注入...
6. php 与java的ioc框架实现的异同
组件的获得,php要手动使用str做为组件名称寻找...java的可以通过注解寻找...
6.1. Phalcon 的问题
Phalcon 是个dll 。。。。。也有对应版本关系。。麻烦。。这个亚能实现di ioc了。。
6.2. 注入 Laravel 虚拟主机安装的问题
wanganlin21 发表于 2013-9-5 09:42
难道url要通过 http://www.domain.com/public 来访问?
毕竟虚拟空间无法将目录绑定到 public 目录上。 ...
是的，如果不支持 htaccess 那就放弃吧。
This solution enables you to drop Laravel into your public folder then use a .htaccess file to redirect requests to the public folder. This solution places your application and core system code into a publicly accessible folder. This is not something that we encourage you to do with any PHP framework.
Step 1. Place Laravel in your document root folder.
Step 2. Place the following .htaccess file in your document root folder.
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_URI} !^public
RewriteRule ^(.*)$ public/$1 [L]
</IfModule>
Step 3. Make sure that you manually set your 'url' configuration in application/config/application.php otherwise Laravel will generate incorrect URLs. Make sure that each of your environments have the correct application.url configuration. For more information on environment-specific configurations see:http://laravel.com/docs/install#environments
That's all.
发表于 2014-9-10 13:59:59 | 只看该作者
| 现在的虚拟主机大部分 php版本 不支持laravel |
7. 淋巴：：atiioc
Laravel重的一塌糊涂、向后兼容性差不说，代码风格方面还用tab来缩进！
Laravel的可借鉴之处例如：IoC,DI,eloquent,Artisan这些Phalcon全都有，性能还更好（能比这个框架快的PHP框架不多了，唯一能抗衡的是YAF吧，但YAF那社区，那文档，呵呵了）。
8. atitit.ioc框架选型 java php
spring guice
phpp::
9. 资料
http://v4.golaravel.com/docs/4.2/ioc
php的微核心容器 PHPiocContainer-CSDN论坛-CSDN.NET-中国最大的IT技术社区.htm
10. 参考
浅谈IOC--说清楚IOC是什么 - DebugLZQ - 博客园.htm
用PHP实现简单的IoC控制反转 -- 简明现代魔法.htm
理解PHP 依赖注入 Laravel IoC容器 - ◆gHOST◇的专栏 - 博客频道 - CSDN.NET.htm
理解PHP 依赖注入 Laravel IoC容器 - ◆gHOST◇的专栏 - 博客频道 - CSDN.NET.htm
Laravel-简洁、优雅的PHP开发框架(PHP Web Framework)。- Laravel中文网（Laravel中国社区.htm
透透彻彻IoC（你没有理由不懂！） - stamen的程序员之路 - ITeye技术网站.htm
atitit.ioc框架选型 java php.doc