当我们重新审视前面的内容时,获得的不仅仅是一个主程序、一个应用程序对象类和一个 Config.fpw文件。获得的应该是对象化的思维模式。虽然,对象化并不一定是银弹,但是,在我们构建自己的应用时,从对象化的角度来考虑问题,通常可以获得一个在大多数情况下可以通用的“模型”,在开发应用程序时,这个“模型”可以让我们节约更多的时间,以便于专注于业务逻辑。
尽管通用的模型有诸多益处,但是,我们应该看到它具有自己的局限性。一旦你成功的建立了一个这样的模型,那么,你就需要经常的对其进行维护,使其可用状态始终保持最佳(不要误解这个说法的含义,它意味着,你需要与时俱进的使其运行态始终与技术及审美的进步保持一致,这可能导致你在其中引入新的技术)。
你可以在我所叙述的内容基础上,使其更具有个性化,例如,你可以将所谓的主界面也抽象为一个类,使用数据驱动技术来完成主界面的配置。
一旦我们进入到程序的主界面,我相信大多数人都会觉得松一口气。因为,无论是进行设计,还是软件操作,我们面对的,绝大多数情况下都是一个个表单。而进行数据处理的表单,应该是占绝大部分。
还有比这更容易的事情吗?我想,看客中会有人发笑:“谁还没写过几行处理数据的代码啊”作为本文的作者,我习惯性的问一句:你真的会处理数据吗?
我们先来看一段代码:
#DEFINE MSGBOX_YES 6
#DEFINE C_MSGBOX1 36
#DEFINE C_DELETE_LOC "Do you want to delete this record?"
#DEFINE C_NOLOCK_LOC "Record could not be deleted because it is being used by someone else."
* Note: Cascading deletes should be handled via RI triggers in DBC!
IF EMPTY(ALIAS())
RETURN
ENDIF
IF MESSAGEBOX(C_DELETE_LOC,C_MSGBOX1) = MSGBOX_YES
DELETE
IF THIS.Parent.UpdateRows() &&success
* Success
IF !EOF()
SKIP 1
ENDIF
IF EOF() AND !BOF()
SKIP -1
ENDIF
ENDIF
THIS.Parent.ButtonRefresh()
THIS.Parent.NavRefresh()
ENDIF
IF THISFORM.ShowWindow = 2
Activate Window (THISFORM.Name)
ENDIF
这段代码,是使用 VFP 的表单向导生成一个表单得到的,它的作用是删除表中的一条记录。它存储在 WizBtns.VCX 中的 txtBtns 类中。
这已经是相当高级的代码了。在这段代码中,首先判断当前工作区中是否存在打开的表,然后让用户确认是否要进行操作,当用户成功删除记录后,恰当的移动记录指针,并刷新相关的表单元素以便它们呈现出在操作逻辑上最合理的状态。我相信,它的代码质量以及可维护性应该可以算是可圈可点的。
然而,你忽略了一个事实。VFP 的表单向导已经出现很久了,它存在的时间,可能比某些看客学习VFP 的时间还要长……尽管这段代码代表了经典的数据处理方式,但是它仍旧没有跳出过程化的范畴。因为,在它出现的年代,在VFP 中,没有直接提供一种手段以便于对象化的处理数据。
从 VFP8 开始,VFP 提供了一个CursorAdapter 类,在 VFP9 中,它得到了完善(为了更好的阐述后面的内容,我翻阅了BOE所写的一些文字,受益匪浅,向前辈致敬!)。这是 VFP 在数据处理方面的最后的绝唱。
之后的文字,让我们看看,在 VFP 中,所谓的对象化处理数据。
你的反馈是我写作的动力,欢迎评论,未完待续。