2. 戒除编写SQL的嗜好

　　编写的SQL越少越好，这似乎与我们的直觉不太一致。对于PL/SQL开发人员来说，这是一个奇特的建议，因为PL/SQL的主要优点之一就是可以毫不费力地在代码中编写SQL语句。不过，这种简易性也是这种语言的一个致命的弱点。

　　可以将纯粹的SQL语句直接置于PL/SQL代码中，而无需JDBC或ODBC之类的中间层。因此，无论何时何地，PL/SQL开发人员只要需要SQL语句，他们通常就会向其应用程序代码中嵌入SQL语句。那么这样做有什么问题吗?

　　在PL/SQL代码中到处使用SQL语句必然会导致以下后果：

　　尽管实际表现不同，但同一逻辑语句仍会出现重复，从而导致过多的语法分析，且难于优化应用程序的性能。

　　暴露商务规则和方案。这直接在SQL语句中包含了执行商务规则的逻辑。这些规则总在变化，所以应用程序的维护成本会急剧增加。

　　当然，你要编写的每一个PL/SQL应用程序几乎都是基于基础表和视图的。你需要执行SQL语句。问题不在于是否执行，而是何时执行、如何执行。

　　如果你对数据结构进行封装，或者将它们隐藏于一个PL/SQL代码层(通常是一个代码包)之后，那么你的应用程序将会更健壮，而且你还会发现创建和维护变得更易多了。

　　我们来看一个简单的例子。 假定我需要编写一个处理某员工工作的程序。第一件事是获取该员工的全名，定义为"姓名逗号(，)姓";然后我可以进行详细分析。清单2给出了这种情况下我很可能要编写的这类代码的一个示例。

　　一切似乎都是这么简单和直接;这些代码可能会有什么错误呢?实际上真是非常糟糕。最主要的是我暴露了一个商务规则：全名的结构。我可能要花费数小时来对此代码及其所基于的应用程序进行测试。但就在它刚刚投入使用时，我才知道客户会不断地打电话告诉我，实际上，他们的全名应该表示为"名空格姓"。

　　现在怎么办?搜索所有位于引号内的单个逗号?

　　现实的解决方案是使用隐藏所有细节、只提供一组预定义、预测试及预优化并能完成所有任务的程序包。清单3为基于封装代码重新编写的process_employee过程。hr_employee_tp包提供了用于定义保存姓名的局部变量的类型;hr_employee_rp包含有基于一种商务规则而返回全名的函数。

　　将显示PL/SQL语句灌入SQL代码很容易，同样，谈论封装这些语句是如何重要也不费劲。但另一方面，编写执行封装任务的代码却具有挑战性;甚至是不现实的。生成这些包或许更有意义。

　　几年前，我曾帮助构建这样一个生成程序。该程序段为PL/Generator，现在由Quest Software公司拥有，PL/SQL开发社区可以免费使用。你可以从我的网站www.StevenFeuerstein.com/puter/gencentral.htm下载。要知道，其封装体系结构与我在前面所概括的约定不同。PL/Generator创建了一个单独的包，它包含了一个表的类型、查询和变化逻辑的全部内容。

　　当你不再编写太多的SQL，而是调用执行SQL的程序时，无论你是生成还是编写自己的定制封装，你的应用程序都会受益匪浅。