现在 asp.net core 开发都用 EF 来操作数据库了吗？还会用 sql 语句去建表和插初始数据吗？

[289396212]

用 EF 是趋势吧？ sql 语句建表和插原始数据（比如省市数据这些）有什么不可替代的点吗？

[idragonet]

有其他 ORM ，例如：CYQ.Data 、SqlSugar

[xuanbg]

我还是喜欢先数据建模，然后手写数据库初始化的 sql 。先深入理解业务，然后才能正确设计数据模型来表述业务。这样后期写代码可以写得比较简单，也不用改来改去。即使需求变化，稍微调整下数据模型也就能够支持新需求了。有时候甚至什么都不用改，也能支持新需求。

[a33291]

部分复杂的统计业务直接用 ef 或者类似的 orm 好像都不好看,还是直接写 sql 比较合适.

推荐一下 ServiceStack.OrmLite

[opengps]

都行啊，你想操作什么都可以，我用 ef 只是省事而已，但我现在接触的工业项目都直接写原始 sql

[kkwa56188]

建表和 插入数据 那都是简单的操作, 替不替代都差不了多少.
SQL 语句 的 核心竞争力 是 灵活高效的 查询 以回应 复杂的业务需求

[acctv2]

EF 只是可以 codefirst ，不是说一定要 codefirst

[qiufengshe]

用 EF,也会用写 SQL,一般的查询会用 EF,复杂的,拿统计来说,会写 SQL 拿 Dapper 查询

[thinkershare]

不管使用什么方式,数据库操作都被放在外围的适配器中,领域模型始终是独立与数据库的. 考虑性能的情况下使用 Dapper 或者干脆写 SQL. 除了性能也业务及其不规范的情况,或者数据库使你无法掌控的情况,还有查询极度复杂(这种情况一般会使用 CQRS), 直接写 SQL 没啥优势,只有缺陷.另外一些特殊的的原子操作会直接使用数据库的触发器.

[idealhs]

EF 一样可以先建表

[roundgis]

用 dapper 也可以

[xiaodei]

用 EF 搞简单的表可以从对象映射到 sql 生成，复杂的表我直接用 dapper,如果项目要求比较高，或者多个人写的话我会简单封装一下，好别人理解

[netnr]

我一直使用的步骤
1. PowerDesigner 进行表设计，再生成建表脚本
2. Scaffold-DbContext 生成实体并强制覆盖更新
3. db.Database.EnsureCreated() 判断不能存在则建表、写入样本数据
4. 更新 PowerDesigner 重复操作 1 、2 步骤

开发 数据库优先，部署 代码优先

[libasten]

ef 可以在有表的情况下，做映射，帮你把模型类生成好，总之，这玩意就是一个工具。

[lujiaxing]

不一定. 有些项目是必须要求先做数据库结构文档的. 例如一些给政府机构做的项目, 当地大数据局事后是可能会要产品的数据结构文档的. CodeFirst 的数据库大概率根本不做这种东西, 数据库结构文档就是实体类. 这种情况下还要现搞数据库结构文档. 所以还不如事先就做好 DBM, 然后从 DBM 直接生产数据库结构和实体类来的方便.

[sl797]

不管是 EF 还是 Dapper ，官方从来没说过只能用一种方案。
都是根据业务场景来的，有的人员和基础数据管理模块上，本身 EF 就足够了。

[sl797]

@sl797 当面对复杂的逻辑时，用 dapper 写复杂查询 也是可以的。 如果是微服务，那就更简单了，业务直接与框架无关

[nightsky]

一般都是 ORM+少量 SQL ，在.NET 上好用的 ORM 不少，比如 EF ，FreeSql 等。但是复杂的场景，还是写 sql 更直接。90%的场景可以用 ORM 解决，剩下的就是写 sql 了