发信人: jetliu()
整理人: catmail(2000-12-05 18:45:39), 站内信件
|
我的第一个数据库程序,是在一个窗体上放了三个组件:一个Table,一个D atasource,一个DBGrid。run了一下,嘿嘿,very well,delphi真棒!相信很多的 朋友都有过如此的经历。
程序写得越来越多,也越来越复杂。每次在Button的Onclick事件里写table .Post或FieldByName('...')=...时总是觉得心里不舒服,万一我不想要这个but ton了,这些代码不就无家可归了吗?有时觉得某个字段用datetime型不如用var char方便,改吧,好了,在run一下编好的程序,每个功能都不正常了,满眼都是 大红叉的异常警告,仿佛程序要崩溃了一样。我渐渐的感到划分层次的重要性。
经过一段时间的摸索,我所理解的数据库程序应该至少由三层组成:数据接口层 、操作层、界面层。数据接口层负责直接和数据库打交道,完成各种基本操作, 如添加、删除,让所有直接和数据库打交道的语句都封装在这一层;数据操作层 高于接口层,封装了所谓的商务逻辑,它的每一个动作,是由接口层的一些基本 操作组成的。界面层处在最上面,尽量少的参与和数据库有关的内容,只负责和 用户交互,收集数据反馈信息。个层之间用记录传递数据。
基于这种思想用vc或c来写程序会感到很顺手,可是一用delphi就会完全走了味儿 。就说delphi的Data control组件,让界面完全直接和数据接口层的Table联系了 起来,使操作层变得很多余。并且我的界面就得直接负起数据维护的责任,不能 很好的和数据隔离开。这样造成了模块之间的耦合太多,导致维护工作变得十分 困难。一旦对数据库结构作即使很小的改动,也会导致程序彻底崩溃。不用data control组件吧,好了,马上有更多的麻烦等着你呢,edit中输入的数据类型校 验要自己写代码;combobox下拉的列表要自己装载和刷新,整个在做重复的无益 劳动,结果只能导致bug的增多。还有就是data module窗口,非要你把所有的ta ble,query放到里面。其实每个数剧源和他所在的模块逻辑联系最强,到了data module里,偏偏要把毫无联系的各个模块的数据源强拉硬拽的放到一起,真是不 理解。
Dephi的数据库开发到底是基于怎样的思想,我看想不通这个问题就别想用好Del phi。
-- 共同探讨,共同提高.
※ 来源:.月光软件站 http://www.moon-soft.com.[FROM: 210.72.251.218]
|
|