Silverlight 快速开发平台-万能实体GOD_MODEL重新思考

Silverlight快速开发平台是一个配置化的开发平台

不可能像具体开发业务系统一样定义数据模型 产生具体的实体类

因为我们的目标是无编码开发业务系统

这样矛盾就产生了，因为是无编码，不可能编码产生具体的MODEL对象来描述具体的领域模型

在Silverlight端绑定数据要求都必须是实体，怎么办？有牛人搞类似DataTable的对象，虽然很牛，但是本人认为不可取！

这样GOD_MODEL这样一个万能实体就应用而生，我们无法设计具体的对象，那我们就设计一个万能的对象，它的能力超乎寻常，包罗万象

它是一个抽象的实体，你看不出它代表什么东西，但是它能代表任意东西

里面定义的属性都是不具体的属性，所以干脆就STR1,STR2，STR3........STR50好了，主要目的是用来承载数据和绑定数据

因为我们是无编码的，所有只要系统能正常驱动执行 比如说 STR1   代表员工姓名，它能正常表示，正常绑定就ＯＫ了，我们

也无需计较它为什么用ＳＴＲ１去绑定，而不是 USER_NAME 这个更直观的名字

无所谓，管它什么呢，正常运行就欧拉。

我们的目标是尽可能的做到无编码，但是完全消除编码那几乎是不可能的，除非这个业务系统实在太简单

最终技术框架总归只能解决技术问题，核心的业务逻辑，不可能全部都组件化了，那这个时候就是开发人员大显身手的时候到了

嘿嘿，终于轮到我上场了！

咦，乖乖个隆滴东，这个什么玩意，怎么都是STR1，STR2，STR3

这下不完蛋了吗，神啊救救我吧，我看不懂啊！

好，这就是个问题，看来是框架的问题。

于是产生了下述的场景

架构师：没有办法啊，我们平台就是基于万能实体这个抽象MODEL来的，不可能是具体的MODEL

程序员：那这个架构下开发就比较麻烦了

架构师：麻烦也就是那一部分需要扩展的代码而已，你看平台多么强大，已经封装的80%的代码不需要开发了，且开发一个画面几乎就5分钟的事情

           更好的就是，你的软件不是开发的而是配置的，随时修改下配置文件软件就快速修改了

           且你都不需要发布，配置是配到我们数据库中的

程序员：想想也是哦，想想这个平台的好，的确，使我从原来的码奴彻底解放出来了，原来几天才能搞定，搞完后还有一堆问题的功能需求，

           现在半小时之内，中间还上一遍厕所，还抽一起烟，时间都不是问题，依然从容搞定，让我有更多的时候关注核心业务逻辑了，有更多的时间思考了。

           嗯……肯定这个平台的确是很强大

           但是接下来的扩展代码还是我来写啊

           想想总有一丝不爽，虽然想到平台的好，这痛消退了很多，但是痛感隐隐还在.

架构师：看着程序员欲言又止的表情，似乎读到了什么感受，做为一个架构师，取得上述的成就，的确是你的价值体现，

            但是留有尾巴，总感觉不够完美

            真的没有办法了吗？难道真的是黔驴技穷了吗？

            NO! 不要这么早就下结论说没有办法，办法总比困难多

            在困难面前永远不要低头，只能说目前没有想到，不代表永远想不到

           这些问题，必须作为一个一个技术点去攻关。

以上：两个角色是我自己对自己的拷问，我认为再高级的架构师必须亲自写代码，否则你不知道你设计的架构在某些方面是多么的不好用。

         也许在某些方面已经出类拔萃，最起码你还能在出色点。

 

问题的解决有其偶然性，但是永远脱离不了人的主观能动性

或许在某个瞬间会有些奇怪的想法在你脑海中闪现

这时候你要顺着自己的思维不断的推理下去，或许不远处就有你想要的答案，没有主动的探究，答案在你眼前你也许都不认识它

在某个下午，在设计另外一个设计的时候，尽然也需要类似的情形，具体到抽象 然后如何从抽象在到具体的问题

也就是前面设计的异步取数据的问题

这里简单描述下需求：Silverlight 在某些场景下需要根据一个Key 取出相关的数据

我们才用配置的方式  在平台平台 配置  如 EP_INFO           select code,name,tel,email,fax from ep_info where id='#conn#'

什么意思 ？我们配置一个查询企业信息的异步数据源

Silverlight 端如何取呢，AJAX('EP_INFO')  OK  这样就搞定了，平台封装好的逻辑，返回的对象都是GOD_MODEL 那个能描述

万物的万能实体 ，这个时候Silverlight 端看到的都是STR1,STR2,STR3

其实开发人员希望这么取  GodInfo["code"]   就比GodInfo.STR1直观多了，具体的还要奢侈的希望 GodInfo.Code 就是永远不可能的，

GodInfo中没有Code的定义

还不要期望那么高，GodInfo["Code"]也OK 类似DataTable的样子，不是不能接受，毕竟我们是配置化平台，没有具体的类。

其实我们希望有一个Mapping映射关系即可，code=str1,name=str2,tel=str3,email=str4

那我们去Code其实就是去GodInfo.Str1这样就解决了，

那如何创建映射关系呢，自己写吗？

如果是自己根本没有解决问题，只是把问题转化了，把使用时的不方便转嫁到创建映射关系创建上了

那么我们肯定是创建GOD_INFO 的时候自己创建Mapping关系了，具体的STR1,STR2其实只是一个数据的载体而已

 select code,name,tel,email,fax from ep_info where id='#conn#'

如上SQL 查出数据，code，name,tel,emial 那么我们统一的异步处理核心代码中就将这些数据从str1,str2一直往后存

存的同时就建立了 Mapping映射关系，code=str1,name=str2,tel=str3,email=str4

这样在SL 端就可以这样 GodInfo["Code"]，也不关心STR1了

    后续再有类似的需求的话，我们就在配置平台配置一个SQL，Silverlight 端就可以快速方便的问题了。

这里提供了一个Mapping的思想

    那么我们的数据字典本身就是在做一种Mapping映射关系。

    只是之前没有想到要这么取值，之前只是想都，GodInfo.STR1

    那么我们也只要在GOD_MODEL 中 设计一个索引器   传入具体业务的属性名，对象自己根据Mapping关系找到具体的抽象的属性 然后返回数据

    OK，这样我们就隐藏了GOD_MODEL的抽象部分。

 

    读完以后，可能大家一头雾水，不清楚这个GOD_MODEL是干嘛的，毕竟这个不是业界的东西，是我们的自主创新设计。

     为什么起名在GOD_MODEL，寓意 "神"

   家宝说了，拍砖是很正常的

  虽然不能像家宝那样把您请到中南海，我依然欢迎大家拍砖，留下您的脚印！