答复: 弱类型是对抗接口易碎的好方法，正所谓无招胜有招。

carlkkx 写道

结论：当我们无法抽象出稳定接口时，我们应该无招胜有招，不变应万变。否则我们的强类型体系必然走向崩塌。

以前发过一篇：

JavaBean和FieldMap 静态定义和动态构建孰优孰劣？
http://www.iteye.com/topic/534249

时至今日我愈发有了这种感悟。

 

引用有所删减 :)

 

我还是很赞同楼主关于数据结构传递的设想的，也就是对于DTO，对于做存储来说使用映射机制比定义一个bean要容易。

 

参考了NoSQL思想、GAE的存储系统+结合了目前公司软件数据的特点来设计的“私有NoSQL”，我的观点有兴趣的可以看：面向对象，真的必须设计数据对象吗？

 

目前现状：

现在自己在设计一个档案存储系统：

界面定义bean类型和字段（包括字段的类型和检查），后台直接创建对应的表结构

bean编辑界面通过定义自动生成，可直接维护对象属性和关系

对外提供底层API：类型+对象ID做为对象定位，类型字段ID+对象ID 定位对象属性值——说白了对外就是个key-value系统，存储时还是bean对应一个表

对外提供高级API：

仿造Ibatis，只要你提供了对象类型+对象类型对应的class+映射处理器（系统本身预定义了一些简单的比如按名字映射，也可以通过xml配置映射，或直接编写adapter class），你可以通过输入Object bean来访问数据

 

查询设计：

底层提供了自定义查询语言MQL，通过antrl分析语法，转化为对应的SQL，发送到数据库中查询

或者

自己访问底层提供的元数据，自己组装sql执行查询

 

特别的：

以上底层数据全部使用memcached做了内存存储

或者

数据量小时直接使用map做为内存存储

 

背景：

问题：你知道的做企业应用的数据对象有多少，一个产品多个现场（>30个现场）的产品个性化的问题？

目标：

 

1. 档案对象维护自动化
2. 档案数据读取简单（比如UtilObject.getProp(propId, objId)即可获得属性值），外部可认为此方法耗用时间可以忽略
3. 业务数据查询简单化（因为不需要考虑档案数据获取的时间了，底层处理数据时只需要针对objID集合对应的数据进行处理，表现在数据库就是select * from 对象的业务数据表 where oid in (???)的形式），此地方不讨论in的性能问题（对于in的使用，在我们的实际系统 40万采集设备，每天96个点，每个点大约24个数据项，4年数据库2T的规模看，未出现特别大的性能问题）——实在不行，可以对数据进行预先加载设计，因为绝大多数业务数据都是只读的

 

 

我的观点就是设计可以结合实际软件特色来做，一定要做适合的底层——也就是专有的系统

 

各个NoSQL产品，剥去它们宣传的仔细看看它们的优缺点，发现都是特别适合它们自己的

有些采用开源的最后还是转向基于开源的设计思想再开发自己的专有NoSQL产品！

 

——成功的产品必然是理论+公司价值磨合而形成的