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关系！