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

我们来看一个JavaBean

class Bond{
private String id;
private String name;

public void setId(String id){
    this.id = id;
}

public String getId(){
    return this.id;
}

public void setName(String name){
    this.name = name;
}

public String getName(){
    return this.name;
}

然后我们来看看对应的FieldMap如何描述：

FieldMap fm = new FieldMap("Bond").putField("id","060001").putField("name","06国债01");

看起来FieldMap简洁许多，毕竟一个是静态定义一个是动态构建，一个强类型一个弱类型。
假设现在要为Bond这个类型加入发行价格和发行日期这两个属性，这时候定义JavaBean时我们将会陷入一个考量，定义什么类型，比如发行日期我们定义Date呢还是字符串？价格定义double呢还是字符串？对于拿日期来做计算或比较的，显然定义Date更合理，如果拿来是显示的显然某种格式的字符串更合适。无论你怎么定义在遇到不同场景时，必然要来回折腾转换，极为不便。
那FieldMap如何处理这样的问题呢？
假设某个Field是发行日期，它的name是iDate，像下面这样我们拿到的是什么？

fieldMap.getField("iDate").getValue();

答案是构造这个FieldMap时放的什么值就是什么值，比如有可能是yyyyMMdd格式的日期字符串，有可能是java的Date类型，如果你仅仅调用getValue（），那么你得到的是当初放的那个值，但是因为你知道这个Field叫iDate，里面的值一定是个日期，所以你有时候说我希望要拿Date，有时候希望要拿某种格式的字符串。因此你不仅仅可以调用Field的getValue（），你还可以这样：

fieldMap.getField("iDate").getDateValue();
fieldMap.getField("iDate").getDateStringValue();
fieldMap.getField("iDate").getDateStringValue("yyyy/MM/dd");

第一个你将直接拿到Date类型，第二个你将拿到yyyy-MM-dd格式的字符串，第三个你将拿到你自定义格式的日期字符串，比如这里就是yyyy/MM/dd。
很明显看到这里我们发现FieldMap灵活便利的多，因为即使对于同一个类型，它也有很多不同的形式。

评论

41 楼 lifetruth 2009-12-18  

个人也是赞同楼主的做法。
FieldMap比DTO优越，本质是控制粒度更细。在c时代就受困于struct的不灵活。

40 楼 steeven 2009-12-16  

我的裸奔界面生成可不能用你这玩意, annotation没地方放啊, 驱动不起来.

39 楼 steeven 2009-12-16  

你看看这好好的OO语言被你糟蹋的, 成了脚本语言啦.
这个玩意应该叫动态bean, 也有人这么用, 存储所有数据都是一个表三个字段. 倒也省心. 我以前做的一个项目也这么干的, 升级什么的很happy, 从来没数据库什么事.
就是计算/查询的时候麻烦点, 还好俺们这种需求不多.

你的那些getXxxValue封装挺贴心, 写成getXxxValue("name")会不会更省心?

38 楼 key232323 2009-12-06  

终于又找到一个以这种思路保存数据的了。

我企图以此构建一个从前台都后台的开发平台（or框架），除了没用作实际项目中，但在做的过程中已经学习了不少。尤其是异构平台下的数据交互，不用再转来转去的了。

关注下，看看lz还有哪些进展

37 楼 carlkkx 2009-12-03  

引用

我目前的实际应用中确实如此，不过得强调给想反驳的人说，这个FieldMap并不适合习惯Hibernate的模式的人。如果你企图对这些碎片对象进行建模，那不仅是徒劳，而且还容易出错。所以我认为，FieldMap不适合用来进行建模，只适合用来处理这种碎片式的数据交互。

基本上同意，如果某种数据你去建模就说明这个数据具有一定的稳定性和核心性，这样这个数据才有了静态定义的价值。而碎片式数据是没有静态定义的价值的。所以像FieldMap这样的动态数据结构在这里就能发挥用处。

36 楼 vlinux 2009-12-03  

carlkkx 写道

引用

大多情况下，实体对象都有各自的含义--这跟客户端不客户端没关系

    一个数据有含义这当然是没错，但是我觉得客户端对于数据的视角实际上是用户使用角度的视角，
这个角度观察数据未必等同于服务器设计的整个数据关系。
客户端--交互1--服务器（拥有完整的数据定义的地方）
      --交互2--服务器（拥有完整的数据定义的地方）
      --交互3--服务器（拥有完整的数据定义的地方）
      --交互4--服务器（拥有完整的数据定义的地方）
      --交互5--服务器（拥有完整的数据定义的地方）

    这些交互1，交互2，交互3等等交互所传递的数据结构，实际上都是一些数据碎片（我自定义的词汇），这些数据结构不一定能够完全对等到服务器上的对象上，它有可能是多个对象某种整合之后的结果，也有可能是某个对象的局部，等等，反正不一定是一致的。而且这些交互1，交互2，所有交互的数据结构加起来未必构成一个完整的数据关系的描述，这些交互1，交互2有多少完全取决于用户的使用视角，这些需求也有可能是易变的。所以客户端如果静态定义Bean，那么就是针对这些数据碎片（交互传递的数据）进行定义，而数据碎片根据以上的描述，一般复用性是很低的，而且如果你的交互非常多的话，那么你定义的Bean就会不断的膨胀。而这个时候类似于FieldMap，FieldMapSet这样的动态数据结构就可以大显身手了，你在客户端本更不需要为了这些交互传递的数据碎片静态预先定义Bean。因为交互本身就是用户使用操作的视角，这是易变的，是动态数据结构大显身手的地方。

我目前的实际应用中确实如此，不过得强调给想反驳的人说，这个FieldMap并不适合习惯Hibernate的模式的人。如果你企图对这些碎片对象进行建模，那不仅是徒劳，而且还容易出错。所以我认为，FieldMap不适合用来进行建模，只适合用来处理这种碎片式的数据交互。

35 楼 carlkkx 2009-12-03  

vlinux看到上面这段论述，应该有共鸣吧。尤其是与异质系统交互时，数据碎片的量可能更大。

34 楼 carlkkx 2009-12-02  

引用

大多情况下，实体对象都有各自的含义--这跟客户端不客户端没关系

    一个数据有含义这当然是没错，但是我觉得客户端对于数据的视角实际上是用户使用角度的视角，
这个角度观察数据未必等同于服务器设计的整个数据关系。
客户端--交互1--服务器（拥有完整的数据定义的地方）
      --交互2--服务器（拥有完整的数据定义的地方）
      --交互3--服务器（拥有完整的数据定义的地方）
      --交互4--服务器（拥有完整的数据定义的地方）
      --交互5--服务器（拥有完整的数据定义的地方）

    这些交互1，交互2，交互3等等交互所传递的数据结构，实际上都是一些数据碎片（我自定义的词汇），这些数据结构不一定能够完全对等到服务器上的对象上，它有可能是多个对象某种整合之后的结果，也有可能是某个对象的局部，等等，反正不一定是一致的。而且这些交互1，交互2，所有交互的数据结构加起来未必构成一个完整的数据关系的描述，这些交互1，交互2有多少完全取决于用户的使用视角，这些需求也有可能是易变的。所以客户端如果静态定义Bean，那么就是针对这些数据碎片（交互传递的数据）进行定义，而数据碎片根据以上的描述，一般复用性是很低的，而且如果你的交互非常多的话，那么你定义的Bean就会不断的膨胀。而这个时候类似于FieldMap，FieldMapSet这样的动态数据结构就可以大显身手了，你在客户端本更不需要为了这些交互传递的数据碎片静态预先定义Bean。因为交互本身就是用户使用操作的视角，这是易变的，是动态数据结构大显身手的地方。

33 楼 carlkkx 2009-12-02  

luckaway 写道

是没看不清楚，名字不一样和对象类类型不一样是有区别的，至少方法重载不了了！！！

FieldMap本身只是作为灵活的数据结构用的，不过很多人定义的Bean通常也只是一个数据结构吧，基本就是个值对象，又有多少要继承还重载方法。

32 楼 luckaway 2009-12-02  

是没看不清楚，名字不一样和对象类类型不一样是有区别的，至少方法重载不了了！！！

31 楼 carlkkx 2009-12-02  

引用

比如Dog和Cat里面的属性都相同，但是它们是不同的对象，如果你用fieldmap描述它们，两者都无法区别了。

可以描述的，可能你没仔细看我一开始写的那行代码：

FieldMap fm = new FieldMap("Bond").putField("id","060001").putField("name","06国债01");  

你发现没有构造FieldMap的时候是要传名字的。

30 楼 luckaway 2009-12-02  

carlkkx 写道

引用

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

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

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

fieldmap在某些场合是能用的到！

大多情况下，实体对象都有各自的含义--这跟客户端不客户端没关系

比如Dog和Cat里面的属性都相同，但是它们是不同的对象，如果你用fieldmap描述它们，两者都无法区别了。
而且fieldmap里的字段名称和数量也是不定的--既是优点，也是缺点！

29 楼 carlkkx 2009-12-01  

引用

在JavaEE年代之前就已经有一个完善的c++后台，然后和前台的交互都是用XML报文。

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

28 楼 carlkkx 2009-12-01  

引用

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

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

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

27 楼 vlinux 2009-12-01  

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

26 楼 hr6r 2009-12-01  

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

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

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

25 楼 carlkkx 2009-12-01  

引用

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

因为我这边客户端并不是浏览器，而是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，也是能带来很多便捷。

24 楼 vlinux 2009-12-01  

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

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

23 楼 carlkkx 2009-12-01  

引用

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

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

22 楼 carlkkx 2009-12-01  

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