Firedac集成在Delphi中已经有几个版本了，偶尔也拖到Form上试着用用，虽然知道Firedac有可能是最终的（或很很长时间内）数据访问技术，可一直不能接受它，其中最大的原因就是过于“复杂” -- 虽然复杂也意味着功能更强大。
就个人的感觉而言，一个好的软件系统，【基础】是好的设计，没有好的设计，意味着软件的生命不会长久，只要不是”一次性“的软件，必然会有升级和维护。
重构就是一种非常好方式，简单的来说，提炼方法，提炼类和接口等等。而针对RAD开发来说，是需要一定的“勇气”的，因为DELPHI实在是太易使用了，基本上设置一些属性，在关键的事件中写写代码就OK了。也正是太容易了，所以很多时候，基本上没有设计。
很早以前，就看到过有人说不用数据感知的组件了，很长时间里，一直觉得不用数据感知组件是本末倒置，舍近求远。（自己也增改造了不少感知控件）
随着时间流失，自己开发的软件积累了不少。每次的改动，都觉得很“烂“ （虽然技巧不少），这里的”烂“，主要是指”结构“烂了，感觉调着调着，真是伤筋动骨啊! ...省略千字...
软件的维护，绝对不是靠着修改N个属性就OK了的。依赖属性越多，就越是铁板一块。而维护的人，也不是靠组件和属性就能深刻的理解业务的，或许写“不需要注释的代码”是不易的，但这是应该追求的。现代盖个巨大的高层建筑很容易，也很快速，但这是在有图纸，有设计的前提下的。
RAD带便利的同时，让人们忽略了设计？？还是人太懒了呢？ Firedac功能越强大，封装的功能很多，我觉得越容易让人依赖于他的属性和功能，尤其是C/S开发上。当然并不是说这些功能不需要，但应该粒度上更细一些，或者单独封装出来，最终让开发者用组合的方式来使用。我个人喜欢dbx的原因就是非常简单，数据的处理必须要自己代码来控制，提炼数据层接口，提炼业务代码，最终用代码描述业务功能。
新的一年马上就要来临了，作为2014年最后的一点想法，感觉有些勿忙和凌乱，有如是不知所言。
