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 就足够了。 |