这里我们必须假设,读者都很了解存储过程,存储过程就是关系型数据库中定义的一个子集。随后,连接到该数据库的并提供了必要认识的用户即可以执行这个存储过程。
我们认为,这里的子程序一词是理解存储过程的知用范围和好处的关键,且这里我们所说的存储过程的适用范围和好处都是其目前的状态。我们承认,10年前人们会对存储过程有不同的看法,且总体来说更加倾向于使用。不过 ,软件领域中的10年是一段相当长的时间,相当于远古和现代。
维基百科上对于子程序的定义是一个大型程序中的一部分代码,用来执行专门的任务并从某种程序上与其它代码独立。在数据库编程中,子程序则表示将几个SQL语句组合起来,组成单一的一个复杂语句,即存储过程。这样调用者即可用统一的
接口与数据库交互,易于保证安全,测试,优化和维护,其运行速度也会有所提升。
上述描述阐明了存储过程的优势和劣势。在不同的上下文中,前面提到的每个特征都可能成为优势或者劣势,这取决于你所创建的应用程序的需求和约束,以及逻辑的最终复杂性和处理复杂性的方式。同样,开发方式的不同也会对于存储过程成为优势或劣势产生影响。
客户的说,存储过程并不是万恶之源。不过对于那些使用现代观点,模式,工具和技术实现的带有一般复杂性的应用程序来说,存储过程被认为是一种过时的技术。我们的观点是存储过程并不是绝对不能使用,而是应该在必要也确定有所帮助时才使用。
在过去的10~15年中,编写系统的趋势是分层并依赖于真正的设计模式,不过仍有一个地方被很多人忽视。人们仍旧经常将业务逻辑放在存储过程中实现,让两个完全不同的层的功能混在一起。你会很容易地不小心将某段业务逻辑放在存储过程中,这样做真的合理吗?以后的几章就列举一些长久以来一直听到的编写复杂存储过程的理由,其中有些理由在10年前可能更加合理一些,不过今天事情已经发生了很多变化。因此,我们在以后几章中介绍一些常见的有关储过程的传言并进行分析,当然,其中会根据现在和以前的技术作出对比分析。
(本文摘自:Microsoft.NET 企业级应用架构设计)href="http://techblog.bozho.net/?p=1173" target="_blank" class="content_href">We Don’t Need That Documentation ]