C# EF Core
0
悬赏园豆：100
[待解决问题]
我在.net core项目中使用EF Core，我是Linq和原生SQL一起在使用，一般是查询用Linq，还有简单的操作（比如新增一条数据，修改一条数据，删除一条数据）这种也用Linq去操作，然后比较复杂的操作，我是直接写原生SQL在DbContext里面去执行的。这种是否算合理的使用？前天去面试的时候，那个面试官说我这样做违背了ORM的本意，大家是如何使用EF Core的？
问题补充：
比如我通过增量的方式从别的系统的接口里面同步数据到我的数据库，那么接口回来的数据可能在本地存在，那我需要更新，本地不存在，那我需要添加。我的做法是新建一张草稿表，然后EF Core AddRange接口回来的数据到这张草稿表，然后使用原生SQL通过这张草稿表和数据表去做修改或新增，这样感觉比较方便
所有回答(6)
0
面试官说的是对的，用了 EF Core，要尽可能避免写原生 SQL
比如，我需要更新一个实体的信息，那么：
1、我需要先查询出来这个实体
2、对查询出来的实体进行属性更新
3、SaveChanges
以上是查了一次，更新了一次，一共操作了2次数据库。如果换成SQL执行的，只需要操作一次数据库，这种是否SQL更优一些
@--澈--: 可以使用 ExecuteUpdateAsync
await context.Blogs
.Where(b => b.Rating < 3)
.ExecuteUpdateAsync(setters => setters.SetProperty(b => b.IsVisible, false));
0
一个系统里可以同时用多个ORM，如增删改用EF，读用SqlSugar、dapper等
没这样用过，后面项目我试试
0
ORM框架，我觉得只是方便开发者更容易操作数据库，不用关心SQL怎么写，SQL注入问题等；并且数据库字段映射为类属性，更容易修改和维护，这些都是ORM的好处；
像楼主一样在EFCore里面ExecuteSql返回模型来完成自己的业务的开发兄弟不在少数，这样做确实将ORM框架的本意违背了，因为破坏了ORM模型和数据库字段的映射关系，因为你随时可以在你的SQL中字段重命名成别的什么，系统的可维护性就会降低，好像回到了很多年前使用ADO.NET，DataTable转换实体的做法
另外，应尽可能将业务逻辑放在程序中，因为你一旦放入SQL，那么执行业务涉及到的业务逻辑、计算等操作都是由数据库服务器来完成，消耗的是数据库服务器的资源。
数据库做为整个系统最宝贵资源应该尽量避免无关的耗费，试想一下扩容一个服务节点和扩容数据库资源这两者的代价有多大；如果一个系统中稍微复杂一点的业务全部由数据库完成，那数据库的压力得有多大，资源到达瓶颈就会出现接口服务没压力，数据库服务器各种报警。
所以，下次遇到这种问题，可以试着从以上角度考虑作答
好的
0
这玩意以前没有的，现在有了，说明微软也觉得有使用场景，某些LINQ真不如SQL简洁
的确
赞同
0
我觉得也还行吧。既然用了EF就尽量不写sql，但是复杂查询不好做也可以写sql。我早放弃EF了，还是写SQL爽，我喜欢用dapper。
0
ORM 的全称是 对象关系映射。
它是一种编程技术，充当了面向对象编程和关系型数据库之间的桥梁。它允许开发者使用熟悉的面向对象编程语言（如 Python、Java、C# 等）来操作数据库，而无需编写繁琐的 SQL 语句。
所以，从orm角度讲是这个逻辑，但是orm做复杂查询就太难为它了，重点用于写操作+简单查询；
复杂查询用dynamic更无敌。dapper是好用的，国内的话sqlsugar直接起飞。国际接轨的话ef可以的。
1、查询优化；
2、外置或者配置sql方便；
3、后期维护方便，不用面向对象的必须有实体类；
4、灵活性强，我更喜欢dyanmic和new匿名类；
单从灵活性考虑，不喜欢orm的实体类逻辑；
不过话说回来，规模的项目要一致性和确定性，所以规则之下，灵活性就没那么重要了。
