现在 asp.net core 开发都用 EF 来操作数据库了吗？还会用 sql 语句去建表和插初始数据吗？
289396212 · 2023-08-12 19:36:39 +08:00 · 2252 次点击这是一个创建于 502 天前的主题，其中的信息可能已经有所发展或是发生改变。
用 EF 是趋势吧？ sql 语句建表和插原始数据（比如省市数据这些）有什么不可替代的点吗？
 |
1
idragonet 2023-08-12 19:44:32 +08:00
有其他 ORM ，例如：CYQ.Data 、SqlSugar
|
 |
2
xuanbg 2023-08-12 19:47:03 +08:00  1
我还是喜欢先数据建模，然后手写数据库初始化的 sql 。先深入理解业务，然后才能正确设计数据模型来表述业务。这样后期写代码可以写得比较简单，也不用改来改去。即使需求变化，稍微调整下数据模型也就能够支持新需求了。有时候甚至什么都不用改，也能支持新需求。
|
 |
3
a33291 2023-08-12 20:00:21 +08:00
部分复杂的统计业务直接用 ef 或者类似的 orm 好像都不好看,还是直接写 sql 比较合适.
推荐一下 ServiceStack.OrmLite |
 |
4
opengps 2023-08-12 20:05:37 +08:00
都行啊，你想操作什么都可以，我用 ef 只是省事而已，但我现在接触的工业项目都直接写原始 sql
|
 |
5
kkwa56188 2023-08-12 20:08:02 +08:00
建表和 插入数据 那都是简单的操作, 替不替代都差不了多少.
SQL 语句 的 核心竞争力 是 灵活高效的 查询 以回应 复杂的业务需求 |
 |
6
acctv2 2023-08-12 20:54:58 +08:00
EF 只是可以 codefirst ，不是说一定要 codefirst
|
 |
7
qiufengshe 2023-08-12 22:06:33 +08:00
用 EF,也会用写 SQL,一般的查询会用 EF,复杂的,拿统计来说,会写 SQL 拿 Dapper 查询
|
 |
8
thinkershare 2023-08-12 22:12:55 +08:00
不管使用什么方式,数据库操作都被放在外围的适配器中,领域模型始终是独立与数据库的. 考虑性能的情况下使用 Dapper 或者干脆写 SQL. 除了性能也业务及其不规范的情况,或者数据库使你无法掌控的情况,还有查询极度复杂(这种情况一般会使用 CQRS), 直接写 SQL 没啥优势,只有缺陷.另外一些特殊的的原子操作会直接使用数据库的触发器.
|
 |
9
idealhs 2023-08-12 22:13:23 +08:00
EF 一样可以先建表
|
 |
10
roundgis 2023-08-12 22:24:45 +08:00 via Android
用 dapper 也可以
|
 |
11
xiaodei 2023-08-13 00:56:11 +08:00
用 EF 搞简单的表可以从对象映射到 sql 生成，复杂的表我直接用 dapper,如果项目要求比较高，或者多个人写的话我会简单封装一下，好别人理解
|
 |
12
netnr 2023-08-13 06:40:52 +08:00
我一直使用的步骤
1. PowerDesigner 进行表设计，再生成建表脚本 2. Scaffold-DbContext 生成实体并强制覆盖更新 3. db.Database.EnsureCreated() 判断不能存在则建表、写入样本数据 4. 更新 PowerDesigner 重复操作 1 、2 步骤 开发 数据库优先，部署 代码优先 |
 |
13
libasten 2023-08-13 07:29:14 +08:00
ef 可以在有表的情况下，做映射，帮你把模型类生成好，总之，这玩意就是一个工具。
|
 |
14
lujiaxing 2023-08-13 11:27:10 +08:00
不一定. 有些项目是必须要求先做数据库结构文档的. 例如一些给政府机构做的项目, 当地大数据局事后是可能会要产品的数据结构文档的. CodeFirst 的数据库大概率根本不做这种东西, 数据库结构文档就是实体类. 这种情况下还要现搞数据库结构文档. 所以还不如事先就做好 DBM, 然后从 DBM 直接生产数据库结构和实体类来的方便.
|
 |
15
sl797 2023-08-13 13:33:29 +08:00
不管是 EF 还是 Dapper ，官方从来没说过只能用一种方案。
都是根据业务场景来的，有的人员和基础数据管理模块上，本身 EF 就足够了。 |
Select Language