第6章数据传输的标准化解析.docx
《第6章数据传输的标准化解析.docx》由会员分享，可在线阅读，更多相关《第6章数据传输的标准化解析.docx（16页珍藏版）》请在冰豆网上搜索。
第6章数据传输的标准化解析
第6章数据传输的标准化
ExtJS除了组件丰富外，另外一个特点就是数据传输的标准化。
那么，这样做，有什么好处？
为什么要这样做呢？
本章将为你解答这些问题。
在搞清楚这些问题之后，就要考虑怎么去实现了。
本章将通过简单的CMS系统来演示数据传输的标准化的基本的实现思路。
1
2
3
4
5
6
6.1标准化的数据传输是什么
在本书所说的标准化的数据传输主要是指，使用代理提交数据时，格式必须统一化标准化，而服务器端在处理提交的数据后，返回的数据格式必须是标准化的数据。
6.2为什么要实现数据传输的标准化
假设要使用ExtJS开发一个非常庞大的复杂的系统，在项目组里有许多开发人员，其中，开发人员A习惯以A方式提交和返回数据，而开发人员B则习惯以B方法提交和返回数据，而开发人员C则需要根据开发人员A和B的数据请求和数据格式返回数据，那么，开发人员C就必须根据开发人员A和B各自喜好的方式去获取提交数据和返回不同格式的数据。
可以想象得到，开发人员C是多么的悲催，估计杀人的想法都有了。
姑且勿论是否存在开发人员C这样的悲情人物，当系统开发完成，进入后期维护的时候，维护人员面对的就是一堆不同格式的提交数据和返回数据，这无疑大大增加了维护成本。
如果以上两种情况，还不足以说明问题的话，那么，当公司需要针对某个客户的需求，需要修改开发平台，进行迁移的时候，就得根据不同格式去进行迁移，这无疑也增大了迁移的开发成本。
因此，实现数据传输的标准化是很有必要的。
6.3标准化数据传输的好处
根据6.1节的描述，标准化数据传输的好处之一就是，服务器端的数据处理可以实现统一化标准化，无论客户端提交的数据是什么，只需要根据标准化统一化的处理过程，就能把数据分离出来并进行相应处理。
通过数据处理的标准化统一化，就可以大大减少重复代码，提高代码的可重用性，而这，无疑是大大的利好。
重复代码的减少，无疑会提高代码的可维护性，而这也是利好之一。
由于客户端接收的是以标准格式的返回的数据，因而，无论服务器端平台怎么变化，只要以这种标准化格式返回数据，客户端代码不需要做任何修改，就能正确处理返回的数据。
因而，标准化的数据传输，对于项目开发平台的迁移，也是有相当大的好处的。
6.4如何实现标准化
既然实现数据传输的标准化是好的，那么如何去实现呢？
这，首先得从ExtJS的数据传输方式说起。
6.4.1ExtJS的主要数据传输方式
ExtJS主要的数据传输方式有Ajax、JsonP、表单和代理这4种方式。
JsonP是用来处理跨域请求的，由于跨域请求会受到另一个域平台返回数据格式的影响，因而只能针对性的进行处理，不一定能以标准化格式进行处理，所以本节就不把它考虑在内了。
不过，如果跨域的平台也是以这种统一的标准化的格式返回数据，那真可以偷着笑了。
下面来研究一下Ajax、表单和代理这三种传输方式的提交格式和返回格式。
1.Ajax
Ajax可以说是ExtJS最基本的数据传输方式，无论是表单的提交或是代理，都是以这为基础的。
当然，表单也可以使用传统的HTML方式来提交，而这，已不在本书讨论的范围，因而，本书所说的表单提交，都是指以Ajax方式提交的表单。
Ajax方式的数据传输，提交数据比较灵活，这个可根据不同的需要灵活处理。
而对于提交后返回的数据，则可以使用统一的数据格式，以便客户端进行处理。
2.表单
在ExtJS中，如果没有特殊设置，表单是以Ajax方式提交，而这，实际上与传统的HTML表单提交区别不大。
因而，对于接收表单的数据，还是要按习惯的方式处理。
而对于表单提交后返回的数据格式，是有特殊要求的，这主要包括两种格式。
第一种格式是字段有错误时的格式，格式如下：
{
success:
false,
errors:
{
field1:
"错误信息",
field2:
"错误信息",
...
}
}
在以上格式中，属性success的值必须是false，以表明表单的提交存在错误，而属性errors则包含了存在错误的字段以及错误信息。
格式中的field1、field2对应的就是表单中字段的配置项name的值。
第二种格式则是没有字段错误，但存在其他错误或者是提交成功后的返回格式，格式如下：
{
success:
true或false,
msg:
"信息"
}
以上格式中，属性success是必须的，true表示表单提交成功，false则表示提交失败。
属性msg则可根据项目的规定或自己的喜好进行定义，但必须与代理使用的属性相同，从而实现统一的返回格式。
3.代理
代理无论是提交还是返回的数据格式，都是有固定格式，但为了保持一定的灵活性，提交格式可由配置项进行定义，如Ext.data.writer.Json的encode配置项，可决定提交数据是以流形式提交还是以HTTP变量的形式提交。
因而，标准化提交格式主要的方式就是使用固定的配置项。
代理的返回格式基本上是固定的，主要格式如下：
{
success:
true或false,
total:
数据总数,
data:
[...],
msg:
"信息"
}
以上格式中的4个属性都可通过配置项进行修改，因而，为了实现标准化，必须固定这些配置项。
6.4.2扩展代理，以实现数据传输的标准化
从ExtJS的主要数据传输方式可以了解到，标准化格式其中一个重点就是标准化代理的提交格式和返回格式，而这，可通过扩展代理来实现。
对代理进行扩展，主要目的就是固定Reader和Writer的配置项，这样，不但实现了数据传输的标准化，还可减少重复代码，提高代码的可重用性。
在实现之前，要先了解哪些配置项是需要修改的，哪些配置项是不需要修改。
对于提交格式，主要是指Ext.data.writer.Json的配置项，包括以下这些：
❑allowSingle：
是否允许提交单个记录，默认值是true，允许提交单个记录。
如果允许提交单个记录，在服务器端，就要对提交的数据先判断提交的是对象还是数组，才能进一步对数据进行处理，这无疑增大了处理难度。
因而，应该毫不犹豫的把它设置为false，无论是单个记录还是多个记录，统一以数组的形式提交到服务器，便于服务器进行处理。
❑encode：
决定数据以什么形式提交，默认值为false，是以数据流形式提交到服务器。
因而，在服务器，需要以读取数据流（类似于读取上传文件）的方式来获取数据，这对许多开发人员来说，会非常的不习惯，也不方便，因而，要毫不犹豫的修改为true，以习惯的HTTP变量方式提交。
❑root：
设置了encode为true后，在服务器使用哪个变量名来获取数据，就需要使用该配置项来定义。
我比较习惯定义root的值为data，这样，在服务器就可以使用data来获取数据。
这个，可根据设计要求或个人喜好来定义。
❑writeAllFields：
是否只提交修改过的字段。
默认值为true，无论字段是否修改过，都会提交。
我习惯提交全部字段，因为在服务器单独提取个别修改字段，不如整体处理来得方便。
对于返回格式，主要是指Ext.data.reader.Json的配置项，包括以下这些：
❑messageProperty：
用来定义返回的数据中，可获取到响应信息的属性，也就是用来定义6.4.1节代理格式中的msg属性的配置项。
这个可根据设计要求或个人喜好设置，我个人偏好于使用msg作为属性。
❑root：
用来定义返回的数据中，可获取到记录的属性。
也就是用来定义6.4.1节代理格式中的data属性的配置项。
这个可根据设计要求或个人喜好设置，我个人偏好于使用data作为属性。
❑successProperty：
用来定义返回的数据中，可获取到数据返回是否成功的属性。
也就是用来定义6.4.1节代理格式中的success属性的配置项。
默认值就是success，一般情况下，不建议修改该属性。
❑totalProperty：
用来定义返回的数据中，可获取到记录总数的属性。
也就是用来定义6.4.1节代理格式中的total属性的配置项。
默认值就是total，一般情况下，不建议修改该属性。
从以上介绍可以了解到，需要定义的配置项主要包括encode、root、allowSingle、messageProperty。
明确了要统一的配置项之后，就可实现扩展代理（以下称为格式化代理）了。
但在实现之前，要考虑是把格式化代理定义在Ext.ux命名空间下，还是定义在SimpleCMS.ux命名空间下。
这两种命名方式的主要区别就在于目录的位置。
一般情况下，通用的扩展最好是定义在Ext.ux命名空间下，这样便于区分，但存在的问题是这些扩展会分布在ext\src\ux目录下，不便于维护，例如，在当前项目，把扩展放到ext\src\ux目录，由于要展开的目录比较深，要找出相应的类还是比较费劲的。
如果放在SimpleCMS.ux命名空间下，最大的问题就是要使用到另一个项目的时候，需要修改命名空间。
以我的经验来说，我偏好SimpleCMS.ux命名空间，主要原因就是便于维护，而这个问题的重点就是Ext本身扩展就很多，因而，在ext\src\ux目录下本身就有很多目录和文件，要在里面找项目的文件比在app\ux目录下找要费劲。
而且考虑到如果要把扩展复制到另外一个项目，直接把app\ux目录复制过去，然后修改命名空间就可以了，而不需要在ext\src\ux目录下一个个找出来再复制过去。
当然，这个问题，可通过预先把所有自己的扩展整合到一个目录，再进行复制的方式来解决，但总的来说，还是不如在app\ux目录下定义来得方便。
提示把自己的扩展放在app\ux的目录的想法来自于ExtJS4.2的示例SimpleTask，然后经过实践，感觉这样确实是方便多了，在解决方案资源管理器中找扩展要依次展开ext→src→ux目录，感觉比较烦人。
建议多点研究一下ExtJS中的示例，会获益良多的。
想法确定后，就可以在Scripts\app目录下依次添加目录ux→data→proxy，然后在proxy目录下添加添加一个名为Format.js的JavaScript文件来定义格式化代理。
这样做的目的是为了将类名定义为SimpleCMS.ux.data.proxy.Format，以符合ExtJS的类命名规则，这个可参考SimpleCMS.ux.data.proxy.Format的父类Ext.data.proxy.Ajax的命名规则，Ajax.js文件就是在data\proxy目录下。
当然，如果图方便，不按照这个命名规则命名也行。
在类名和父类都已经清楚的情况下，要写出类的定义代码也就不难了，代码如下：
Ext.define（'SimpleCMS.ux.data.proxy.Format',{
extend:
'Ext.data.proxy.Ajax',
}）
为了能像Ext.data.proxy.Ajax哪样，在定义代理的时候，可使用值为ajax的type配置项来指定使用Ext.data.proxy.Ajax代理，就必须定义别名，也就是定义alias配置项。
在Ext.data.proxy.Ajax中，别名的定义为“proxy.ajax”，再观察一下其他代理类的别名定义，都需要添加“proxy.”作为前缀，因而，在格式化代理的别名中添加前缀是必不可少的。
而我打算用format作为格式化代理的别名，因而，格式化代理的完整别名会是“proxy.format”。
别名定义好以后，就要统一读取器的格式了，要统一的配置项主要包括root和messageProperty，代码如下：
reader:
{
type:
'json',
root:
"data",
messageProperty:
"msg"
},
代码中，由type配置项
升级会员 