首页 > 代码库 > 关于Firedac的一点看法

关于Firedac的一点看法

Firedac集成在Delphi中已经有几个版本了,偶尔也拖到Form上试着用用,虽然知道Firedac有可能是最终的(或很很长时间内)数据访问技术,可一直不能接受它,其中最大的原因就是过于“复杂” -- 虽然复杂也意味着功能更强大。

就个人的感觉而言,一个好的软件系统,【基础】是好的设计,没有好的设计,意味着软件的生命不会长久,只要不是”一次性“的软件,必然会有升级和维护。

重构就是一种非常好方式,简单的来说,提炼方法,提炼类和接口等等。而针对RAD开发来说,是需要一定的“勇气”的,因为DELPHI实在是太易使用了,基本上设置一些属性,在关键的事件中写写代码就OK了。也正是太容易了,所以很多时候,基本上没有设计。

很早以前,就看到过有人说不用数据感知的组件了,很长时间里,一直觉得不用数据感知组件是本末倒置,舍近求远。(自己也增改造了不少感知控件)

随着时间流失,自己开发的软件积累了不少。每次的改动,都觉得很“烂“ (虽然技巧不少),这里的”烂“,主要是指”结构“烂了,感觉调着调着,真是伤筋动骨啊! ...省略千字...

软件的维护,绝对不是靠着修改N个属性就OK了的。依赖属性越多,就越是铁板一块。而维护的人,也不是靠组件和属性就能深刻的理解业务的,或许写“不需要注释的代码”是不易的,但这是应该追求的。现代盖个巨大的高层建筑很容易,也很快速,但这是在有图纸,有设计的前提下的。

RAD带便利的同时,让人们忽略了设计??还是人太懒了呢? Firedac功能越强大,封装的功能很多,我觉得越容易让人依赖于他的属性和功能,尤其是C/S开发上。当然并不是说这些功能不需要,但应该粒度上更细一些,或者单独封装出来,最终让开发者用组合的方式来使用。我个人喜欢dbx的原因就是非常简单,数据的处理必须要自己代码来控制,提炼数据层接口,提炼业务代码,最终用代码描述业务功能。

新的一年马上就要来临了,作为2014年最后的一点想法,感觉有些勿忙和凌乱,有如是不知所言。

 

关于Firedac的一点看法