ORM产品给我们带来了哪些思考？

现在流行的对象关系映射技术产品得以存在，它们能被大的服务器提供商（包括IBM等）认可，它们有很多优点，这是不可否认的。对象关系映射技术产品使用XML或依赖注入的方式实现数据库结构的映射，这种思维方式已经固化了，已经被被奴化的架构师们、被奴化的码农们、被奴化的猎头们、被奴化的项目经理们普遍的接受，过去很少有人怀疑过。但是，我个人认为这种方式不科学、不合理，我相信有此同感的人不止我一个。原因有以下几点：

数据库的结构信息被人为地物理地重复定义一遍，系统架构变得复杂，软件工程文档的数量成倍增加；如果没有这种重复的物理的数据库结构定义，它们什么都干不了。

软件产品维护困难，如果需要修改数据库的结构，就必须修改XML映射的定义或者修改注入，这给修改Java源代码人为地增加了一道由中间环节带来的困难，而在整个系统的实现过程中，数据库表的结构变化是很正常的，可能会是频繁的；如此折腾，给整个软件工程带来的额外的工作量是非常大的。

如何改善基于流行ORM产品的软件工程的效率，伴随这一问题的ORM产品的衍生产品应运而生，这是技术的进步？还是人力、技术、财力等资源的浪费？还是ORM产品带来的不是问题的问题？这些为ORM产品服务的衍生产品主要的任务就是配置XML映射文件。

重复定义数据库结构信息，根本上就是一种错误的决定，是上述不合理性的根本原因。JDBC是各大数据库供应商共同遵循的标准，而数据库的结构信息对于JDBC来说完全是透明的，XML映射、注入映射完全是多余的画蛇添足的作法。

如果你是系统架构师，在使用ORM产品解决以下问题时，请问该怎么做？

怎样查询数据库的结构信息？

怎样实现两个不同数据库之间的数据交换？

客户需求变了，数据库的表的结构变了，需要修改那些软件工程文档？需要修改那些源代码？

对于以上问题，如果任由你自由发挥，你又会怎么去做？

以上问题并非虚构，而是非常有现实意义的问题。如果在我们的软件设计过程中，能方便的查询数据库的结构信息，就可以智能化的处理数据的CRUD操作，比如：自动过滤掉无效字段，只提取有效字段，并将有效字段保存到数据库中，否则，会异常。对于两个不同数据库之间的数据交换，不需要依赖XML映射、不需要注入映射，那该有多好，这样就可以方便地实现数据库的迁移、数据的备份等等。客户需求变了，表的结构变了，我们不需要管那么多的XML映射、注入映射，只需要修改局部的Java源代码，那该有多省事。

ORM产品，我们差不多已经使用了十年，有多少成分是客观的选择、理性的选择？有多少成分是盲目的选择？

科学技术的进步需要我们打破墨守成规的思维，应当学会用实事求是的精神去面对别人给我们规划的条条框框，寻求开拓创新。只有这样才能更好地促进中国软件技术水平的进步，中国的软件技术才能更多地为世界做出贡献。