存放在Session有一些弊端，不能实时更新，服务器压力增大等…
要求:将从BO拿回来的数据存放在UI Cache里面，数据库更新了就通过RemoveCallback "告诉"UI Cache，实现更新。
环境：BO 提供一个WebService给UI取数据，UI也有一个WebService，提供给BO 通知UI更新数据。数据结构的原生类始终在BO层。
本来是想在数据库Update 后，在BO将Cache的数据推送至UI Cache，但其中遇到了自己解决不了的问题:
数据结构转换问题:
大家知道WebService数据通过一个数据协议，将数据序列化成xml传送。
UI Call BO的WebService取数据，数据原生结构在BO，数据也在BO，UI期望得到的数据结构是对BOWebService引用生成的Reference.cs里面自动生成的。
UI取数据可以成功。
但是BO Call UI WebService推送数据的时候就成问题了：
BO Call UI的WebService，数据结构很应该是在UI层定义的(个人理解) ，但是现在数据结构的原生类始终是在BO层里面的。
BO数据原生结构
UI引用BO WebService生成Reference.cs
个人以为在BO 引用UI WebService生成Reference.cs时，EntyAuxiliary又会变了另外一个样子(因为UI的EntyAuxiliary是BO来的，而现在BO又引用UI的EntyAuxiliary，说的复杂点就是BO引用了UI引用BO的EntyAuxiliary)
但是BO引用UI WebService生成的Reference.cs代码里:EntyAuxiliary还是这个样子。
基于以上，BO Call UI WebService：
ReSetCacheData(string key,Object data);
报错:
就算我把原生类数据结构的数据转换成Reference.cs的数据结构也是报同样的错误。
为什么呢？
逼于无奈之下，只好就需求改一改:数据库Update的时候，BO Call UI WebService，让UI自己重新Call BO WebService取回更新后的数据。
这样的方式就是BO通知UI，让UI自己去取数据，而达不到BO推送数据的好处了。
通知方式和UI轮询BO是否有数据更新方式 这样的方式是否效率比较低下呢？个人比较不喜欢…
和W讨论过：现在普通的Call WebService流程是，第一种:UI主动Call BO,通过RQ 传送数据，UI主动Call BO，通过RS接收数据。
RQ,RS都是在BO层定义的，两次方式都是UI做主动。
第二种:而我的情况是,UI 主动Call BO取数据，而BO 主动Call UI 推送数据。这就是不同点。
W说 客户端和服务端之间通过WebService传送数据 的方式应该要像第一种。
我BO Call UI 推送数据的时候，数据结构就应该由UI层定义，但是我想：我UI有从BO WebService引用的Reference.cs自动生成了EntyAuxiliary，，就把Reference.cs里面的EntyAuxiliary当做是在UI定义的数据结构不行吗？ 在BO推送数据的时候，我还把原生类的数据转换成了Reference.cs里面的EntyAuxiliary，结果还是不行。。
可能归根结底UI层需要接受的数据类型的原生类型是在BO层里面定义的吧？
以下两张图片是个人记录..
缓存的思考：
问题：
自己要先看得起自己，别人才会看得起你
