【问】ASP.NET中是否应当尽量将所有的T-SQL写成存储过程？

Question

RT。请说明理由。Thanks……88分祝您发发~~~

Answer 1

建议楼主看看Nhibernate。了解Nhibernate后数据库方面的工作就很少了。而且也不用写sql语句了。唯一麻烦的就是配置问题了。

Answer 2

存储过程便于维护
而且很多时候，效率要比在代码中拼sql好

Answer 3

存儲過程速度快,但維護難,如果你不能直接管理服務器或者表結構經常變化,還是在C#里寫好了.
T-SQL相對速度慢,好維護.
自己平衡.

Answer 4

一味的极端追求也不好。
有些时候需要对数据库进行优化，那么针对不同的操作要写大量的存储过程，维护起来也不容易。
有的时候可以考虑适用参数化SQL语句。

Answer 5

方便维护，效率比SQL语句高，安全性比较好。

Answer 6

最好尽量写成存储过程，可以防数据库注入。。以前用过Nhibernate挺不错的

Answer 7

具体情况具体分析
 当涉及到大量的数据来回操作,可以考虑用存储过程. 一般人使用存储过程主要是为了sql参数化, 减少被注入的可能.其实 写sql参数化语句也是一样可以的. 执行效率上, 我没发掘存储过程会快多少 
大量的存储过程会给后期的移植带来一定的麻烦  比如 sql--->oracle ,

Answer 8

存储过程，过程过程，一般要多条语句并且有逻辑关系的SQL比较适合写为存储过程。你不能指望只有一条语句的存储过程带来性能提升。以下来自MSDN：在 SQL Server 中使用存储过程而不使用存储在客户端计算机本地的 Transact-SQL 程序的好处包括： 存储过程已在服务器注册。
存储过程具有安全特性（例如权限）和所有权链接，以及可以附加到它们的证书。用户可以被授予权限来执行存储过程而不必直接对存储过程中引用的对象具有权限。
存储过程可以强制应用程序的安全性。参数化存储过程有助于保护应用程序不受 SQL Injection 攻击。有关详细信息，请参阅 SQL Injection。 
存储过程允许模块化程序设计。 存储过程一旦创建，以后即可在程序中调用任意多次。这可以改进应用程序的可维护性，并允许应用程序统一访问数据库。 
存储过程是命名代码，允许延迟绑定。这提供了一个用于简单代码演变的间接级别。
存储过程可以减少网络通信流量。 一个需要数百行 Transact-SQL 代码的操作可以通过一条执行过程代码的语句来执行，而不需要在网络中发送数百行代码。

Answer 9

我一般是sql语句较长的写成存储过程，其它的都在程序中传参。

Answer 10

大部分人都认为存储过程比较快，其实这是一个误解实际上存储过程快是由前提的，比如说一些修改，删除的存储过程，从理论上说会要比执行SQL语句快但是一些查询存储过程，最简单的特例就是有查询字符串作为参数传入的时候，存储过程不见得比SQL语句快
原因：当条件是参数的时候，sql server不能根据条件推断出最优的执行路径，因此存储过程不一定使用的最优执行路径来执行。但是执行SQL语句，作为条件的参数已经被确定，因此sql server能根据条件推断出最优执行路径，执行速度很有可能比存储过程快。总结：当你对数据库不是特别了解的时候，或者没有DBA参与你的项目的时候，能不用存储过程就不用
当你对数据库了解得很透彻，或者有资深DBA参与你的项目，这个时候用不用存储过程就看你自己了

Answer 11

 存储过程，这个东西其实也不见得一定好用，想现有些代码生成工具，能直接生成非常好用的增、删、改、查的cs代码，其实就是拼接的Sql字符窜，使用很方便，没必要用存储过程去实现，能达到快速开发。

Answer 12

在linq和orm横行的时代，还在考虑这个问题。

Answer 13

如果是多条语句的执行，我觉得应该用存储过程，如果只是单句SQL，我还是习惯写在代码中，担心拼接字符串的话，可以使用StringBuilder来做。

Answer 14

存储过程修改方便，就是是项目发布了，也可以直接修改，方便扩展
存储过程在前几年，项目中使用很多，随着硬件和三层、多层结构地发展和LInq ,ORm等的使用
存储过程已很少使用了。   在防注入和参数化方便还可使用
   
    

Answer 15

没有一个完美的方案，根据需要是写sql,还是ap,是自己拼接sql,还是有底层帮你拼接sql.没种方式都有优缺点，把握一个度和平衡就可以了，没必要这么极端。
哈，路过。