传统的sql方法VS ORM
Pan*_*ema 1 c# sql orm entity-framework dapper
我真的很沮丧地搜索这个答案,哪个更好 - 传统的System.Data.SqlClient方法或使用任何ORM,如EF或Dapper我通过许多链接看到了很多比较,有些是:
我能理解的一件事是,手写的传统sql代码在性能上优于任何其他方法.但是我仍然想到,如果我们已经拥有最好的方法,那么ORM为什么呢？
是否只是因为我们想减少DataLayer代码？或者我们不想管理我们的数据库,并希望在我们的c#代码中编写所有内容(代码/数据优先)
为什么EF被引入,如果只有代码管理是问题那么,为什么以及我们如何妥协查询执行的性能和速度,甚至ORM都有限制.
请回答我的问题,如果需要任何编辑,请告诉我.
我唯一担心的是网站的速度和性能.
提前致谢.
Bac*_*cks 12
我将尝试根据我的经验回答您的所有问题:
为何选择ORM？ORM在Model-First方法中非常出色.当您拥有模型(您的类,对象,实体......)并决定将其保存到某个存储(例如DB)时.在这里你采取合适的ORM并告诉它"好吧,这个班级去这个表"等等.这样可以缩短您的开发时间.当然,你在映射上有一些开销.但是,根据我的经验,我没有映射的性能问题.我在所有其他部分(数据库查询,UI渲染,WCF,...)中遇到了性能问题,但没有ORM映射.所以,ORM缩短开发时间,不显着降低性能.
ORM减少重复,降低复杂性并大大增加开发时间!
用C#写一切？部分 - 是的.ORM提供了强大的映射,因此几乎不可能犯愚蠢的错误,例如比较int和string,将null设置为不可空的属性等等.因此,ORM与LINQ-provider可以保护您的代码.
您对性能的担忧被夸大了.当然,EF(或其他ORM)比手写的SQL代码慢.我相信在99%的情况下,EF会满足您的要求并且维护这些代码要容易得多,它是自我保护和自我解释的.
所以,不要看数字.它们与现实生活没有任何共同之处.如果您需要一些额外的,我会尝试解释.
小智 6
我想补充一点,Dapper的比较图表有点误导,实体框架有一个反对 - 一个很长的启动时间(图表中的631ms).但这只是针对数据库的第一个查询,其中模型和内存中构建了一个模型.
ORM可以为您做的一件事是编写完全高度优化的SQL查询,而在最后您不必担心SQL语法以及如何将POCO映射到数据库表.像任何其他IEnumeration一样使用ORM对象.
PS:更喜欢这个评论,但<50 Rep :(
| 归档时间： |
|
| 查看次数： |
3828 次 |
| 最近记录： |