最近群里来了个大牛，比较才发现自己的差距，嘿嘿，以前是不知天高地厚的，好事好事。讨论下了SQL Server 2005中的托管SP的应用场景问题，结论主要归结如下：
1、解决写T-SQL SP处理逻辑运算比较麻烦的问题。
这个问题要分多个方面来看待：
首先，T-SQL SP的定位是基本的CRUD的I/O操作无法取代；托管SP的作用不是为了取代它的价值。这样来看就不用为托管SP操作数据的写法和直接在业务层里面写Ado.NET相似而介怀了。
其次，托管SP用于处理数据的逻辑运算的原则是Near Data，但是这样看起来和架构设计的责任分离原则又有冲突：通常是不建议存储过程里面有业务逻辑的，不利于移植迁移以及系统扩展。如何处理这样的矛盾，关键在于，选择使用托管SP来写逻辑运算的都是一些需要往返参数较小，但却需要大量操作运算的过程，比如：用户的登录验证，传递的只有用户名和密码，返回是否对某些操作有授权，但却需要对数据库做大量的查询，数据间关系运算操作，因此这种应该用SP来做，使用托管SP会更方便。（往返数据小，数据处理复杂）
2、托管SP弥补了T-SQL SP在部署管理方面的一些缺陷
正如上面关于用户登录授权的问题，部分业务放在SP中并没有体现出托管SP的必要性来。T-SQL SP最大的问题是移植和扩展性上，那么如果业务部分换成托管SP，在部署时候托管SP肯定比T-SQL SP更具灵活性和可移植性，而才基本的CRUD操作方面，各个数据库之间的差异并不是很大。
3、托管SP在安全性方面比T-SQL更好。这个我没有太明白，他提到的是利用CAS，不清楚这是什么东西了。
主要就这三个方面的思考，其他还有一些发散，不如例举了在SQL Server里面调用Web Services，这种情况还是遵循是否该选择SP的原则进行；以及提及到了存储过程的继承？呵呵，这个需要更多一些讨论了。