事由：当一个请假单记录要保存之前，要检测较多的条件。其中检测这个动作可以由三个方面来完成：客户端、服务器的C#代码、数据库的存贮过程
这个问题一直困扰着我，我的检测代码到底写在哪里，我只隐约感觉存贮过程可能会更好，于是把检测内容准备移进存贮过程，但接着就发现更多问题，于是把两者进行一次比较（仅限于自己目前的能力），看到底是放在哪好。
（客户端的JS代码以后再说，因为客户端完全可以不检测，或者说客户端检测得再多，服务端也是要重复进行检测的）
C#代码 SQL存贮过程
复用性 中 好
维护-可读性 好 中
维护-调试 好 差
编程方便性 好 差
测试 中 好
性能-运行速度 好 中
性能-网络交换量 好 中
面对变化的适应能力 中 差
部署 好 好
复杂度 好 差
用户体验 中 差
复用性：
C#代码无法在VB6中使用，而存贮过程检测的逻辑则可以被VB6简单直接地重复使用后来查了，有C#中生成DLL，让VB6调用的（要试一个看其复杂度有多少）
http://read.newbooks.com.cn/info/175321.html
维护-可读性：
注释功能大家都有，C#中还有代码折叠功能，SQL中有直接看到SQL语句的好处，并且不必建立连接、关闭连接等操作，但C#可以通过函数来弥补。如果子程序完善，连接SQL再执行语句获得返回值象吃饭一样简单，那C#就好过SQL了。
维护-调试：
调试时的变量的查看与修改，以及边调试边修改代码，这些SQL大大不如C#
编程方便性：
主要是指智能提示，代码格式标准，代码语法性错误，这也是SQL大大不如C#
测试：
如果要对SQL中的存贮过程进行自动测试，可以非常容易实现，因为存贮过程关联得比较小。而对C#中的子程序测试，好象问题蛮多的，包括要构建Session，Request等内容，自己把握小一些。
性能-运行速度：
使用C#检测条件，不必动到数据库的，也就不必连接之类的操作（这时忽然想起来，如果不必使用数据库的检测，其实JS端就完成了，会不会JS检验+存贮过程检验=OK），速度会快，而存贮过程的检测，至少要调用一个连接存贮过程这个动作。
但对于要使用数据库的数据时，C#的速度一定没有存贮过程快
性能-网络交换量：
这里是指如果数据库与IIS不在同一台服务器上时的网络交换量，与运行速度结果类似，对于不用连接数据库的，C#好，对于连接数据库的，SQL好。
面对变化的适应能力：
变化是指要增加一个检测条件时，如果入口参数没有变化，存贮过程只要改一下，就没事了。C#代码则是改完代码，编译，部署。
如果入口参数有变化，存贮过程一调整，当前操作的用户就要出错了。可以通过一定的方案让存贮过程的入口参数不必调整，方案如下：
我们准备把客户端传过来的参数传给一个存贮过程时发现，最经常变化的就是这些参数的个数，有时多一个，有时少一个，有没有办法让参数恒定。代码不受参数个数的变化而变化。后来想了一种方法，即把客户端的参数一古脑儿地扔到一个表中，然后只传递记录的ID给存贮过程，由存贮过程自己去取，取出来设置成具体参数再进行处理。
1、把获取到的参数保存到一个表中，甚至，就是一条字符串
2、调用存贮过程时，只传该记录的ID
3、存贮过程再从该表中获取信息
也正是因为这个问题，才想到写这篇文章的。
部署：
由于我现在知道C#如何部署时不中断当前用户，因此对其内容的修改不会有特别的影响，两者对部署不会差异太大。
复杂度：
如果使用存贮过程，则也是要经过C#代码这一段传送，这样做凭空多了一层，增加复杂度。
用户体验：
是指询问用户的情况，用存贮过程不容易实现，用C#则相对来说还是方便的。
总结：
比较后，很明显，我的预感是错的，C#原来的一些缺点被克服后，对比一下，C#好多了。今后再对复用、自动测试、适应变化这三个方面加强一下，就可以义无反顾地在C#中写入大量的检测语句了。
