在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的程序时，无论你是生成还是编写自己的定制封装，你的应用程序都会受益匪浅。
评论加载中…
 |