书契所使用的并不是VFPAED的完全架构，从上一篇文章我们可以看出，每个Framework都要储存自己的Data/Provider/Action/Event，
很显然我们说过，Data是极少的，而书契分为了Common/Project/Code/Plugin/Cloud 5个 Framework，
将Data分散在5个Framework中会造成很大的浪费，并且结合书契的实际情况，其Action和Event数量也没必要分散到5个Framework中，
于是我决定增加一个全局框架(GlobalFramework)来储存所有Data/Action/Event/Provider。
但这样就出现了一个问题，事件需要有作用域，也就是说在某些情况下，事件不会在全局生效，而是只针对某个作用域生效，
于是我又增加了单元框架(UnitFramework)，每个单元框架拥有自己的事件管理器，用于处理事件，
这样就可以针对不同作用域触发事件。
与此同时，我们发现，这样的亚完全架构使得耦合度增加了，于是我决定使用依赖注入在一定程度上进行解耦，
（主要的原因还是因为依赖注入很便于使用） ，将GlobalFramework作为IOC容器，来储存需要自动装配的数据(Provider/Action/Event/Data等)，
然后制定相应的注解规则，以及支持从构造方法进行数据注入和对字段进行数据注入，注入数据需要数据来源，
那么怎么得到需要装配的数据呢，很显然需要一个数据装配控制器来控制数据的获取，对于每个数据的获取，我们可以使用策略模式，
分发到不同的类去进行处理，虽然会产生很多策略类，但这样能够保证外部插件也能够定义自己的可装配数据。
也许各位读者也可以试试这样的VFPAED-DI亚完全架构，这是一种新的体验。
