ExtJS也玩依赖注射(DI)?

简介: ExtJS 组件的 Xtype 大家都是了解的,就是为了方便组件的“延时渲染”而设的。类似地借助字符串标识,我们可不可以应用 Store 的引用上呢?ExtJS 3.0 提供了这方面的支持,允许我们配置组件期间,不获取真正的 Store 对象而告知组件正确的 Store 是哪一个。

ExtJS 组件的 Xtype 大家都是了解的,就是为了方便组件的“延时渲染”而设的。类似地借助字符串标识,我们可不可以应用 Store 的引用上呢?ExtJS 3.0 提供了这方面的支持,允许我们配置组件期间,不获取真正的 Store 对象而告知组件正确的 Store 是哪一个。一探究竟,不禁要问是怎么办到的?的确,正如大家所料,还是像 Xtype 用字符串标识对象那样子就可以了。不过字符串乍听来来,貌似不那么专业和显得非常普通。呵呵,感觉这东西不好说。干脆换种叫法是,——什么来的? 那个……“依赖注射(Dependency Injection)”。——大抵变相的说法即如此。

如上述,使用 Store 注射的场景应该是,当前的上下文没有已构建完毕 Store 对象立刻组装到对应的组件中。因为调用 Store 服务不属于 Ext 组件的生存周期的一部分,有可能出现组件已渲染完毕,仍处于没可用数据的状态,此时可认为 UI 与数据源的通讯是异步的。如此一来,组件模型中就务必引入 Store  的标识引用(Identifier of the store)。

Store 标识在 API 定义中就是“storeId”,如下例所示:

orderStore = Ext.extend(Ext.data.JsonStore, { storeId: "orderStore_1", constructor: function() { orderStore.superclass.constructor.call(this, { fields : [ // Fields ] }); } });

storeId: "orderStore_1"配置好之后,就可以在组件中直接使用 id 引用对应的 Store。如下列的 orderGrid:

orderGrid = Ext.extend(Ext.grid.GridPanel, { title: "订单列表", store: "orderStore_1", width: 400, height: 250, initComponent: function() { this.columns = [ // Columns ]; orderGrid.superclass.initComponent.call(this); } });

注意这里的 store: "orderStore_1"其类型是字符串,Grid 组件才会去查询 id 为 "orderStore_1"的Store对象。如果在旧版的 Ext 中不支持 Store 的依赖注射的话,输入字符串的值就会报错。

因为我们知道,Store 其 id 与 Store 本身的一一对应不能够“隔空取物”,当中必定有联系在一起的机制。那么在 API 中这个类就是 Ext.StoreMgr,它是一个单例(Singleton)。其实 StoreMgr 的实现非常简单,整个类代码如下:

/** * @class Ext.StoreMgr * @extends Ext.util.MixedCollection * store组管理器。这是全局的、并且是缺省的。<br /> * The default global group of stores. * @singleton */ Ext.StoreMgr = Ext.apply(new Ext.util.MixedCollection(), { /** * @cfg {Object} listeners @hide */ /** * 登记更多的Store对象到StoreMgr。一般情况下你不需要手动加入。任何透过{@link Ext.data.Store#storeId}初始化的Store都会自动登记。 * Registers one or more Stores with the StoreMgr. You do not normally need to register stores * manually. Any store initialized with a {@link Ext.data.Store#storeId} will be auto-registered. * @param {Ext.data.Store} store1 Store实例。A Store instance * @param {Ext.data.Store} store2 (可选的)Store实例2。(optional) * @param {Ext.data.Store} etc... (可选的)Store实例x……。(optional) */ register : function(){ for(var i = 0, s; s = arguments[i]; i++){ this.add(s); } }, /** * 注销一个或多个Stores。 * Unregisters one or more Stores with the StoreMgr * @param {String/Object} id1 Store的id或是Store对象The id of the Store, or a Store instance * @param {String/Object} id2 (可选的)Store实例2。(optional) * @param {String/Object} etc... (可选的)Store实例x……。(optional) */ unregister : function(){ for(var i = 0, s; s = arguments[i]; i++){ this.remove(this.lookup(s)); } }, /** * 由id返回一个已登记的Store。 * Gets a registered Store by id * @param {String/Object} id Store的id或是Store对象。The id of the Store, or a Store instance * @return {Ext.data.Store} */ lookup : function(id){ return typeof id == "object" ? (id.events ? id : Ext.create(id, 'store')) : this.get(id); }, // getKey implementation for MixedCollection getKey : function(o){ return o.storeId || o.id; } });

Ext.StoreMgr 直接继承于 Ext.util.MixedCollection,此 MixedCollection 乃 Ext 的专用集合类。本来小弟觉得,没必要用上 MixedCollection,使用 JS 的 Array 岂不是更简单?但由于 MixedCollection 封装了更方便的排序、遍历、增加/删除等的功能,出于这方面的需求,使用 MixedCollection 的话又是合理的,Array 则太过简单化。总之这是一个取舍的问题,若考虑客户端优化为先的就应该只用 Array 吧。值得一提的是,Ext.apply(new Ext.util.MixedCollection(),{……}); 不失为创建单例的一个灵活的用法。

p.s: 上述 Ext.StoreMgr 源码引用的是ext3.0,3.3的 lookup() 方法可能更周全的考虑,请大家鉴别。

按照 register() 源码注释所说的,一般情况下你不需要手动加入 Store 到 StoreMgr,通过 Ext.data.Store.storeId 初始化的 Store 都会自动登记到 StoreMgr。当组件开始调用Store 的时候,就会执行 this.store = Ext.StoreMgr.lookup(this.storeId); 这样的语句来查询 Store,其中 this.storeId 就是 Store 的 id。

最后免责声明一下,专业名词 DI 不是俺安在 Ext 头上的啊。依赖注射的方式有几种,字符串注射也算一种吧。以前看过一下 DI 的资料,但是必须坦白,再问俺深一点就不知道了。所谓 DI For Ext.data.Store,乃源自是 Miami 这位仁兄如是说的……

目录
相关文章
|
监控 容器
浅入ABP系列(3):增加日志组件、依赖注入服务
浅入ABP系列(3):增加日志组件、依赖注入服务
275 0
|
9月前
|
设计模式 前端开发 Java
项目开发-依赖倒置、里式替换、接口隔离的应用深入理解
项目开发-依赖倒置、里式替换、接口隔离的应用深入理解
86 0
|
前端开发 Java 应用服务中间件
SpringMVC——框架概述&第一个注解的SpringMVC程序
SpringMVC——框架概述&第一个注解的SpringMVC程序
SpringMVC——框架概述&第一个注解的SpringMVC程序
|
自然语言处理 JavaScript 前端开发
JS中的依赖注入 — 在测试中未使用过的最佳工具
让我来为大家介绍在测试中最好的朋友。
JS中的依赖注入 — 在测试中未使用过的最佳工具
|
缓存 中间件 API
从壹开始前后端分离【 .NET Core2.0 +Vue2.0 】框架之十 || AOP面向切面编程浅解析:简单日志记录 + 服务切面缓存
代码已上传Github+Gitee,文末有地址   上回《从壹开始前后端分离【 .NET Core2.0 Api + Vue 2.0 + AOP + 分布式】框架之九 || 依赖注入IoC学习 + AOP界面编程初探》咱们说到了依赖注入Autofac的使用,不知道大家对IoC的使用用怎样的感觉,我个人表示还是比较可行的,至少不用自己再关心一个个复杂的实例化服务对象了,直接通过接口就满足需求,当然还有其他的一些功能,我还没有说到,抛砖引玉嘛,大家如果有好的想法,欢迎留言,也可以来群里,大家一起学习讨论。
1440 0
|
XML JavaScript API
从壹开始前后端分离【 .NET Core2.0 +Vue2.0 】框架之九 || 依赖注入IoC学习 + AOP界面编程初探
更新 1、感谢@dongfo博友的提醒,目前是vue-cli脚手架是3.0.1,vue的版本还是2.5.17,下文已改,感谢纠错! 2、代码已经同步到码云https://gitee.com/laozhangIsPhi/Blog.
1921 0