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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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