ECI_AJAX是在ASP.NET快速开发平台中设计的
在客户端快速方便获取数据库数据的一种方式
只要在统一配置平台配置SQL语句即可 这样在HTML端就能方便的获取对应的数据项
是一种根据业务需要封装的异步处理单元
那现在在Silverlight快速开发平台如何使用此概念?
有没有必要使用此概念?
现在有如下场景:通过放大镜选择了客户信息,然后需要根据客户的信息自动出N多其他信息,
诸如联系人、联系电话、EMail等
有人要说,直接设计在放大镜中就可以了,选择了,自动带下去,考虑…… 感觉也OK
就将放大镜做大做强
好OK,我看行那就放大镜好了,
那如果我们执行的某个操作不是放大镜,但是需要根据某个关键值去带一些其他的信息呢?这时要如何?
这个时候你能想到的最简单的:调用WCF 后台执行一个SQL查询出所要的数据
对的,就是这样
其实这类问题大部分都很简单,就是一个SQL查询一下,返回
那么这么简单的事情,同时又是普遍存在的问题,何不用技术手段去封装呢?提供一个更简单的使用方式
ECI_AJAX 表中配置 代码,SQL
这样在使用的时候 Get("代码"),就出来对应的数据了。SQL语句通过统一配置平台配置,可以灵活调整,无需修改程序码
Silverlight平台不能使用Dataset要完全面向对象,那我们查询出来的数据全部放在GOD_MODEL对象中
GOD_MODEL对象的属性都个不具体的描述形式
那如何让开发Silverlight端的程序方便的访问数据呢,那需要真实数据项和抽象数据项之间的一个Mapping关系
比如说具体的数据项 CODE 存储在抽象对象的 STR1 属性中
STR1要对开发人员透明,这纯粹是平台设计的产物
那么我们需要CODE=STR1的对照关系
什么时候建立此映射关系?
例如:WCF端 SELECT 1 AS CODE,2 AS NAME,3 AS TYPE FROM DUAL
这样我们的GOD_MODEL 对应的存储是STR1,STR2,STR3
在产生GOD_MODEL的时候创建Mapping关系,同时将数据一并返回给Silverlight端
是要返回两个对象吗?
感觉这两个东西应该是一个整体的,光有GOD_MODEL 里面全部是抽象的数据,我们无法方便的获取对象数据
Mapping关系是辅助我们获取GOD_MODEL数据的
那意思是说我们这设计这个万能的GOD_MODEL的时候要,设计一个存在Mapping关系的数据结构
这样就不存在两个一起返回的问题了,就是返回一个GOD_MODEL,其中包含了数据和映射关系
思考中……
这个Mapping的机制能否应用到字典中
在字典中,比如说查询,那是否是每个对象 都有一个Mapping关系在里面,那是否额外造成网络数据量的问题
一个对象还马马虎虎,那这个要如何?是否有其它的处理方式
其实字典本来就是在定义Mapping关系!