任何系统都有固定的部分，也有变化的部分。固定的部分是系统的根基，变化的部分是系统的枝叶。枝叶可以生长或枯萎，但根基绝对不能死掉。

一般来说，算法就是固定的部分，信息就是变化的部分。也许不同的信息要采用不同的算法，我们也能用表驱动的方法（也就是虚函数的原始概念）来处理问题能考虑到的特殊信息。

但如果还有没有考虑到某些特殊的信息，就只有改算法，也就需要改固定的根基。这将动摇整个系统。

为了解决这一难题，我们又发明了元数据和脚本语言来处理那些想不到的信息。因为，针对不可预料的信息，我们可以定义新的元数据和编写新的脚本来处理。这样就不用更改系统的根基了，系统也运行的很好。

以上的一切设计都是为了维护的！

好了，O/R Mapping把现实对象定义成了编程语言的类，生成了用C#,Java,或DELPHI描述的代码，又把这些变成了数据库字段。再经过人工优化这些代码，系统已经可以正常运行了。

这时，需求变了，要更改业务，比如要加减些数据字段。天哪！为了加减某些属性，我那些经代码又要重新生成，再修改和调试。

这是为什么？

因为，O/R Mapping一开始设计时就把业务对象看成了内存对象，于是，本来可能变化的需求也就变成了编程语言的“硬代码”，注意是“硬代码”，而不是“元数据”。这就必然导致需求修改而不得不改代码的问题，尽管有辅助工具。

而如果你先在数据库里设计业务模型，那些增加减少的字段不过是数据库的元数据而已。而你的应用程序代码完全可以基于元数据来编写，这正好符合数据集编程方式。这样，增加减少字段不过是修改元数据即可，代码为啥要动？

我也对现在的模型驱动编程表示担忧，因为它们大都建立在当前的O/R Mapping基础之上的。如果，完全能做到不需要手工调整和优化代码，也许能行，但没有那个产品能做到，都是“辅助”而已。

我更倾向于“数据字典”驱动的开发模式，还是数据集编程方式，但是基于数据字典的元数据编写代码，而不是“硬代码”。

所以，“好的思想加速设计，好的设计容易维护”，完全正确！