我在几个项目中使用了实体框架.在每个项目中,由于存储过程的众所周知的好处 – 安全性,可维护性等,我已经使用映射到实体的存储过程.但是,99％的存储过程是基本的CRUD存储过程.这似乎是否定了实体框架 – SQL生成的主要的,节省时间的功能之一.
我已经阅读了有关存储过程的一些参数,而实体框架中生成了SQL.虽然使用CRUD SP是更好的安全性,由EF生成的SQL通常比必要更复杂,它是否真的购买任何在性能或可维护性使用SP？
这是我相信的：
>大多数时候,修改SP需要更新数据模型
无论如何.所以在可维护性方面并不是很多.
>对于Web应用程序,与数据库的连接使用特定于应用程序的单个用户ID.所以用户甚至没有直接的数据库访问.这降低了安全性的好处.
>对于一个小的应用程序,性能略有下降
生成的SQL可能不是很大的问题.为高
音量,性能关键应用,EF甚至是一个明智的
选择？另外,是生成的insert / update / delete语句
由EF真的那么糟糕？
>将每个属性发送到存储过程都具有自己的性能惩罚,而EF生成的代码仅发送实际更改的属性.当对大型表进行更新时,增加的网络流量和更新所有属性的开销可能会抵消存储过程的性能优势.
话虽如此,我的具体问题是：
我上面列出的信仰是否正确？现在ORM正在越来越受欢迎,总是使用SPs“老派”的想法？在您的经验中,使用EF更好的方法是使用所有插入/更新/删除的映射SP或使用EF生成的SQL进行CRUD操作,并且仅使用SP来处理更复杂的东西？
解决方法
我认为总是使用SP是有点古老的学校.我以前用这种方式编写代码,现在我可以在EF生成的代码中做任何事情,当我有一个性能问题或其他特殊需要时,我再加上一个策略性的SP来解决一个特殊的问题.它不一定是或两者都使用.
所有我的基本CRUD操作都是直接的EF生成代码 – 我的网络应用程序以前拥有100个或更多的SP,现在一个典型的将有十几个SP,其他一切都在我的C#代码中完成….我的生产力已经消失通过消除95％的CRUD存储过程.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。