当我们重新审视前面的内容时，获得的不仅仅是一个主程序、一个应用程序对象类和一个 Config.fpw文件。获得的应该是对象化的思维模式。虽然，对象化并不一定是银弹，但是，在我们构建自己的应用时，从对象化的角度来考虑问题，通常可以获得一个在大多数情况下可以通用的“模型”，在开发应用程序时，这个“模型”可以让我们节约更多的时间，以便于专注于业务逻辑。
尽管通用的模型有诸多益处，但是，我们应该看到它具有自己的局限性。一旦你成功的建立了一个这样的模型，那么，你就需要经常的对其进行维护，使其可用状态始终保持最佳（不要误解这个说法的含义，它意味着，你需要与时俱进的使其运行态始终与技术及审美的进步保持一致，这可能导致你在其中引入新的技术）。
你可以在我所叙述的内容基础上，使其更具有个性化，例如，你可以将所谓的主界面也抽象为一个类，使用数据驱动技术来完成主界面的配置。
一旦我们进入到程序的主界面，我相信大多数人都会觉得松一口气。因为，无论是进行设计，还是软件操作，我们面对的，绝大多数情况下都是一个个表单。而进行数据处理的表单，应该是占绝大部分。
还有比这更容易的事情吗？我想，看客中会有人发笑：“谁还没写过几行处理数据的代码啊”作为本文的作者，我习惯性的问一句：你真的会处理数据吗？
我们先来看一段代码：
代码语言：javascript复制#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 中，所谓的对象化处理数据。
你的反馈是我写作的动力，欢迎评论，未完待续。
