倒退的历史？——某MIS项目手记（2）：为什么不用存储过程？
上一篇随笔没想到会引起这么大的关注和争论，搞得我写这篇的时候不得不字斟句酌，慎之又慎。不过博客嘛，贴出来就是让大家评论的，在大家的评论中能让我和需要的读者学到点东西，这目的也就达到了。闲言少叙。
第二篇：为什么不用存储过程？
我在研究这个项目的结构和代码时又发现了一个问题：业务层与数据层之间的交互全部使用直接的SQL语句，而没有编写一个存储过程。也就是说，在VB.NET代码中时不时的就能看到长得要折成三四行才能写下的SQL语句字符串。这样好吗？为什么不用存储过程来实现这些长长的SQL语句，然后在业务层调用呢？
存储过程是什么？用它有什么好处？这里引用SQL Server联机帮助里面关于存储过程的一小段概述：
存储过程可以使得对数据库的管理、以及显示关于数据库及其用户信息的工作容易得多。存储过程是 SQL 语句和可选控制流语句的预编译集合，以一个名称存储并作为一个单元处理。存储过程存储在数据库内，可由应用程序通过一个调用执行，而且允许用户声明变量、有条件执行以及其它强大的编程功能。
存储过程可包含程序流、逻辑以及对数据库的查询。它们可以接受参数、输出参数、返回单个或多个结果集以及返回值。
可以出于任何使用 SQL 语句的目的来使用存储过程，它具有以下优点：
1.可以在单个存储过程中执行一系列 SQL 语句。
2.可以从自己的存储过程内引用其它存储过程，这可以简化一系列复杂语句。
3.存储过程在创建时即在服务器上进行编译，所以执行起来比单个SQL语句快。
SQL Server 中的存储过程与其它编程语言中的过程类似，原因是存储过程可以：
1.接受输入参数并以输出参数的形式将多个值返回至调用过程或批处理。
2.包含执行数据库操作（包括调用其它过程）的编程语句。
3.向调用过程或批处理返回状态值，以表明成功或失败（以及失败原因）。
使用 SQL Server 中的存储过程而不使用存储在客户计算机本地的 Transact-SQL 程序的优势有：
1.允许模块化程序设计。
2.允许更快执行。
3.减少网络流量。
4.可作为安全机制使用。
上面这些其实我觉得已经说得挺明白了，而且根据我个人的经验，可以把写存储过程的工作交给专门的人，他们的工作可以作为连接数据层与业务层的桥梁，更重要的是如果理想的话，他们可以起到对业务层屏蔽数据层变化的作用。还有就是作为业务层开发人员，我个人是不愿意看到数据库查询语言的实现细节出现在我的代码中的。当然这并不是因为我不爱学习，讨厌SQL而喜欢c#、VB.NET；相反如果让我去负责写存储过程，我会专门钻研SQL而不用太关心业务层中的实现细节。
而且退一步讲，即使需求不变，数据库设计人员也有可能，并且有义务去不断优化本来就是一个有机整体的数据库的设计。而现在数据层与业务层紧密耦合的结构会使得数据层每一点变化都会影响到业务层的具体实现，也就是这两层之间的界面名存实亡，起不到它应有的作用。
进一步观察这个项目中业务层的结构发现，这里面绝大部分Class都是数据库中某一个表的再现，其中的数据成员就是表中的所有字段，其中的方法就是Insert、Update和Delete，并且它们全部都是公有的。这些Class又都继承自一个名为TableBase的基类，其中几乎就全是关于表的操作，另外还有一些校验方法。这样就明白的说明这些类只不过就是业务层中的“表”，而非“thing with responsibility”。进而更加明确的说明业务层和数据层的耦合是如何之紧密。
那么这种结构好不好呢？欢迎大家讨论。我个人认为不是很好。
我认为应该将这种紧密的耦合解开以减弱数据层变化对业务层带来的冲击，降低维护的成本。所以我觉得应该使用存储过程来搭建这两层之间的桥梁，作为它们之间的缓冲地带。
同事并没有旗帜鲜明的反对我的想法，他只是说没用存储过程是因为存储过程不好调试，而且大家已经习惯于在程序中写SQL语句了。
我没有多想同事给出的原因，而继续我的思路：现在的存储过程能否完成我上面所说的那种桥梁纽带的作用呢？依我看还不太行。
现在的存储过程已经够“结构化”了，但是还不够“面向对象”。它们至少从外表上看起来还只是一组函数，或者说是一组带执行权限的函数。如果能使存储过程系统更加的面向对象，使之能完成对数据层的封装，那就理想了。那样的话便可以在存储过程的设计上下些功夫，并在适当的时候应用设计模式，使存储过程真正发挥出其位于数据层与业务层之间的重要作用，以使得整个系统在应对不断变化的需求时不再像我们现在一样如此的吃力。
最后一段纯粹为本人异想，也可当作YY，各位看官见笑了。
未完待续
下篇预告：倒退的历史？——某MIS项目手记（3）：服务器控件惹谁了？
第二篇：为什么不用存储过程？
我在研究这个项目的结构和代码时又发现了一个问题：业务层与数据层之间的交互全部使用直接的SQL语句，而没有编写一个存储过程。也就是说，在VB.NET代码中时不时的就能看到长得要折成三四行才能写下的SQL语句字符串。这样好吗？为什么不用存储过程来实现这些长长的SQL语句，然后在业务层调用呢？
存储过程是什么？用它有什么好处？这里引用SQL Server联机帮助里面关于存储过程的一小段概述：
存储过程可以使得对数据库的管理、以及显示关于数据库及其用户信息的工作容易得多。存储过程是 SQL 语句和可选控制流语句的预编译集合，以一个名称存储并作为一个单元处理。存储过程存储在数据库内，可由应用程序通过一个调用执行，而且允许用户声明变量、有条件执行以及其它强大的编程功能。
存储过程可包含程序流、逻辑以及对数据库的查询。它们可以接受参数、输出参数、返回单个或多个结果集以及返回值。
可以出于任何使用 SQL 语句的目的来使用存储过程，它具有以下优点：
1.可以在单个存储过程中执行一系列 SQL 语句。
2.可以从自己的存储过程内引用其它存储过程，这可以简化一系列复杂语句。
3.存储过程在创建时即在服务器上进行编译，所以执行起来比单个SQL语句快。
SQL Server 中的存储过程与其它编程语言中的过程类似，原因是存储过程可以：
1.接受输入参数并以输出参数的形式将多个值返回至调用过程或批处理。
2.包含执行数据库操作（包括调用其它过程）的编程语句。
3.向调用过程或批处理返回状态值，以表明成功或失败（以及失败原因）。
使用 SQL Server 中的存储过程而不使用存储在客户计算机本地的 Transact-SQL 程序的优势有：
1.允许模块化程序设计。
2.允许更快执行。
3.减少网络流量。
4.可作为安全机制使用。
上面这些其实我觉得已经说得挺明白了，而且根据我个人的经验，可以把写存储过程的工作交给专门的人，他们的工作可以作为连接数据层与业务层的桥梁，更重要的是如果理想的话，他们可以起到对业务层屏蔽数据层变化的作用。还有就是作为业务层开发人员，我个人是不愿意看到数据库查询语言的实现细节出现在我的代码中的。当然这并不是因为我不爱学习，讨厌SQL而喜欢c#、VB.NET；相反如果让我去负责写存储过程，我会专门钻研SQL而不用太关心业务层中的实现细节。
而且退一步讲，即使需求不变，数据库设计人员也有可能，并且有义务去不断优化本来就是一个有机整体的数据库的设计。而现在数据层与业务层紧密耦合的结构会使得数据层每一点变化都会影响到业务层的具体实现，也就是这两层之间的界面名存实亡，起不到它应有的作用。
进一步观察这个项目中业务层的结构发现，这里面绝大部分Class都是数据库中某一个表的再现，其中的数据成员就是表中的所有字段，其中的方法就是Insert、Update和Delete，并且它们全部都是公有的。这些Class又都继承自一个名为TableBase的基类，其中几乎就全是关于表的操作，另外还有一些校验方法。这样就明白的说明这些类只不过就是业务层中的“表”，而非“thing with responsibility”。进而更加明确的说明业务层和数据层的耦合是如何之紧密。
那么这种结构好不好呢？欢迎大家讨论。我个人认为不是很好。
我认为应该将这种紧密的耦合解开以减弱数据层变化对业务层带来的冲击，降低维护的成本。所以我觉得应该使用存储过程来搭建这两层之间的桥梁，作为它们之间的缓冲地带。
同事并没有旗帜鲜明的反对我的想法，他只是说没用存储过程是因为存储过程不好调试，而且大家已经习惯于在程序中写SQL语句了。
我没有多想同事给出的原因，而继续我的思路：现在的存储过程能否完成我上面所说的那种桥梁纽带的作用呢？依我看还不太行。
现在的存储过程已经够“结构化”了，但是还不够“面向对象”。它们至少从外表上看起来还只是一组函数，或者说是一组带执行权限的函数。如果能使存储过程系统更加的面向对象，使之能完成对数据层的封装，那就理想了。那样的话便可以在存储过程的设计上下些功夫，并在适当的时候应用设计模式，使存储过程真正发挥出其位于数据层与业务层之间的重要作用，以使得整个系统在应对不断变化的需求时不再像我们现在一样如此的吃力。
最后一段纯粹为本人异想，也可当作YY，各位看官见笑了。
未完待续
下篇预告：倒退的历史？——某MIS项目手记（3）：服务器控件惹谁了？
