ksm*_*ksm 3 .net sql stored-procedures
我们正在设计企业应用程序,我们的技术架构师建议"让代码中没有sql查询.即使对数据库进行简单的select调用,也应该在数据库中为它编写存储过程代码应该调用它."
我的问题是,在整个代码中只有存储过程并且没有任何查询似乎是一个愚蠢的想法!我们的家伙对这个想法深信不疑,但我对此表示怀疑......你们有什么话要说？
如果它是一个好主意,我会喜欢它,如果有人能告诉我支持它的原因.
如果这是一个坏主意,请告诉我他们可以提出什么论点来说服他们.
感谢您的帮助.
thx -ksm
这是支持存储过程的开放理由:为什么要使用存储过程？
我还要添加:正确编码,存储过程可以像方法一样对待:它有返回类型(dataset(s)),参数等
说,我现在倾向于:
没有"是"或"否"的答案
我对通过存储过程执行所有查询的看法
第1点:
在DAL层不是很常见的日子里,它确实非常有用,因为通过SP执行它可以提供相同的信心,即数据库更改永远不会影响除1之外的任何覆盖层.
如今,由于DAL层是常态,你可以使用DAL获得相同的分离,而且我并没有真正看到在这方面拥有SP的额外价值.(拥有DAL层假定您的SQL查询仅在您的DAL中而在其他地方)
第2点:
此外,在较旧的数据库(至少SQL Server 7甚至2000)中,由于缓存SP执行计划而导致性能优势,因为执行直接SQL会因此而变慢.
现在,大多数数据库也会缓存即席查询,这种好处也不再是一个标准.
第3点:
此外,在旧系统中,许多业务逻辑曾经嵌入数据库中.将业务逻辑嵌入数据库意味着编写LONG和复杂的过程.因此,由于程序无论如何都存在,因此通过说"让一切都成为程序"来使它保持一致变得有用.
现在,大多数应用程序都避免将业务逻辑放在数据库的任何位置.因此,除了SELECTS之外,CRUD语句很可能在大多数面向对象的系统中非常简单和直接.
简介:我个人认为强制每个查询的SP都是老式的.有没有伤害到这样做.但是,如果你有一个DAL /业务层和一个足够好的数据库引擎来缓存你的查询查询计划,我真的很难想到这样做有什么好处.