JavaBean和FieldMap 静态定义和动态构建孰优孰劣？

恩，这里细细品味还是有点味道，因为之前，恩应该说现在正在遇到这种情况。我确实被迫定义了非常多的JavaBean去对付来自后台的查询（一个查询接口得两个JavaBean去映射，请求一个，返回一个，甚至两个）。如果用这样的数据结构确实能解决我不少的问题，不过我还可以直接用JQuery去解析那些XML报文为JSON对象，这是我之前考虑的解决方案。
你觉得呢？用JavaScript去解析XML为JSON对象你觉得怎样？

FieldMap只是LZ自己定义的数据结构罢了，呵呵。
我在想，是不是可以用来解决我的一些问题，因为目前我遇到的情况是：后台查询出的结构，我如果定义成JavaBean去与之绑定，那么我的JavaBean复用率非常低...此时如果我每个请求都必须用2个甚至多个JavaBean去映射，那我的类会无限膨胀...而且是事实我已经遇到了...

当然，我前边反对的观点是建立在作为后台稳定通用接口上的，此时JavaBean的复用率比较高，用JavaBean绑定XML的方式是要比FieldMap合适。

解析那些XML报文为JSON对象，这是我之前考虑的解决方案。
你觉得呢？用JavaScript去解析XML为JSON对象你觉得怎样？
————————————————————————————
我觉得只要有好的自动化工具直接将XML转化为JSON对象，而且处理JSON对象又非常方便的话，那当然也不错。

这种情况我有过体会，客户端静态定义大量的与服务器沟通的数据结构，实在是麻烦而且数据结构没有什么复用可言。

恩，想想，出于安全考虑，还是不能直接由浏览器做这么重要的后台XML报文封装的操作。而且一些关键的数据：比如当前登录的操作员编号等，还是从后台的Servlet给出比较好。

特定环境下，用你的FieldMap这种数据格式会比较合适，至少在我这里比较合适。我会在下个项目中，如果还是C++作后台，Java作前台，之间用XML交互的情况，我会建议我的上级采用FieldMap这种数据结构去替代现有大量膨胀的JavaBean，也许会加一些改进。比如加入xpath支持以应对复杂点的XML结构...

因为我这边客户端并不是浏览器，而是Java Swing客户端，所以没有你说的这些问题。
我现在封装的通信API类似于这样：

   FieldMap fm = new FieldMap("Bond").putField("id","060001").putField("name","06国债01");    
    CommonRemoteMsgService.requestRemoteService("服务名",fm,new CommonMsgCallback(){  
        public void onMessage(CommonMsg msg){  
            if(msg.isError()){  
               //错误处理  
            }  
            else{  
              //正常处理  
             msg.getFieldMap();  
           }  
       }  
   });  

实际上我后面还要进一步做FieldMap与GUI绑定的部分，就像前面说的这些：FieldMapFormBinder,FieldMapSetListBinder,FieldMapSetTable
这些弄完了对于开发效率才有比较大的提升，对于一般的CRUD将非常方便的完成，即使不是一般的CRUD，也是能带来很多便捷。

lz 的想法是很多人(特别是老板级别)的想法.

共同点就是 : 妄想用一个通用的的东西来解决所有的问题.

fieldmap 这样的数据存储结构玩玩还可以. production 上用这样的设计我认为是不能接受的.

哈哈，如果他这么想，确实是妄想了。不过貌似能解决某些特定环境下的部分问题。
我是对我遇到的情况中类不可复用是有着及其确定的把握的。情况真的很特殊，并不是所有的IT公司都和我所遇到的一样，在JavaEE年代之前就已经有一个完善的c++后台，然后和前台的交互都是用XML报文。

没有什么东西可以解决所有的问题，有句名言怎么说的来着：不要对整个世界抽象，只对你的问题域抽象。
客户端维护大量的静态数据结构实无必要，也可能我是轻量级惯了。

我这边一个后台，连C++都不是，是纯C，呵呵。