发信人: 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]
|
|