一套告诉你 CURD 操作就没有?
比如 超强 UI 脚手架。。 从 ES Redis MYSQL 一些列中间件 一键勾选自动生成,所有基本库操作
从追踪连到日志分析,性能警告
就没有这样的东西吗?
1
nowheremee 2021-07-09 16:40:13 +08:00
没有银弹。
|
2
fishily1993 2021-07-09 16:44:47 +08:00 11
我很感激没有这种东西,要不然我就只能去要饭了
|
3
IgniteWhite 2021-07-09 16:49:05 +08:00 via iPhone 20
C R U D
https://en.m.wikipedia.org/wiki/Create,_read,_update_and_delete 不是 curd 。curd 是凝乳。取 crud 因为 crud 这个词本身有渣渣的意思。造句:我是一个只会 CRUD 的 crud |
4
heheda11 OP @IgniteWhite 谢谢提醒
|
5
wangxin13g 2021-07-09 17:27:15 +08:00 4
上一个想这么玩的 DW 坟头草已经三尺深了。
|
6
shaojz2005 2021-07-09 17:37:08 +08:00
低代码平台就是尝试解决这个问题嘛
|
7
bthulu 2021-07-09 17:44:31 +08:00
光一个好用的 orm 框架, 没有真泛型的语言都实现不了.
|
8
polyang 2021-07-09 17:56:32 +08:00
还好没有这东西,不然还要我们干嘛
|
9
infun 2021-07-09 18:10:40 +08:00
不同的业务有不同的需求,不同的领导有不同的偏好
|
10
dji38838c 2021-07-09 18:13:22 +08:00
一共才四个字母,天天都要做,顺序都还说不对
可见还是很有必要继续下去。 |
11
pkoukk 2021-07-09 18:18:43 +08:00
我在家做饭的时候也感叹于做饭的繁琐,为啥没有省力的解决方案。
目前的方案再方便,洗菜、切菜、炒菜、洗碗也是分开的。 |
12
3dwelcome 2021-07-09 18:19:44 +08:00 1
@wangxin13g DW 一开始方向就错了,Web 工具就不应该走传统客户端设计的路线。
就应该在线设计,类似 figma 那种可见即可得,模板式傻瓜开发。 然后帮客户自动托管网站,托管数据库,托管 CMS 后台。DW 如果起初能对接在线数据库,也不会死那么惨了。 要想把 CRUD boys 干掉,就必须把数据库和后台一锅端。 |
13
maemual 2021-07-09 18:23:59 +08:00
单纯 CRUD 可以搞啊。但是有什么用的。哪家需求这么弱呢。
|
14
msg7086 2021-07-09 18:25:50 +08:00 via Android
只是 crud 的话 rails 还可以吧,再多了就不清楚了。
|
15
walpurgis 2021-07-09 18:27:25 +08:00
通用解决方案的整合速度赶不上底层组件的迭代吧,看现在招聘市场主流的 Springboot Vue React,出现也就 10 年不到,被市场认可也就 5 年左右,哪有几十年
这两年迭代速度稍微放缓,低代码平台概念又开始火了,我寻思这不都以前玩剩的,只不过用了新的基础技术套个新名词 |
16
NewYear 2021-07-09 19:54:19 +08:00
@maemual
OA 系统啊,企业里各种表单,需求非常大,快速设计界面,权限(分字段)、审批流、报表、字段运算(公式)、表单关联和回写数据、消息推送…… |
18
DoctorCat 2021-07-09 20:49:03 +08:00
桌面软件开发时代,RAD 开发的意思。但是 VB 与 Delphi 也凉凉的,都是换汤不换药。
|
19
zzyphp111 2021-07-09 21:21:26 +08:00
我记得当年织梦系统就是这样的,完全不需要 crud,全都是 ui 操作,那还是 2010 年....
|
20
c88155745 2021-07-09 23:07:54 +08:00
你想失业,还是想更内卷呢。
|
21
littlewing 2021-07-09 23:21:26 +08:00
小网站和系统有低代码可以尝试,大的系统,CRUD 只占很小一部分
|
22
JerryCha 2021-07-09 23:23:47 +08:00
C: 指 A 部门 B 角色 C 岗位具有 D 资质但不是 E 编制的人可以向 F 部门 G 角色 H 岗位且与 E 编制下 I 不存在利益关系的员工提起一个 create 操作申请,批准后交由 J 部门随机指定一名具有 K 权限的人进行创建。
|
23
BeautifulSoap 2021-07-09 23:46:31 +08:00 via iPhone 2
程序员都自嘲说只写 CRUD,但实际上想想 CRUD 是干嘛的?是用来完成业务逻辑的。
业务逻辑代表着现实世界中千变万化无比复杂的需求,业务逻辑就是现实,那么请问世上真的能有这么一个模型或框架可以覆盖绝大多数的业务逻辑吗?答案肯定是不存在的,世上没有银弹。即便是 CRUD 根据不同的业务需求,实现方式都会有巨大的变化,自然就不存在什么一劳永逸大而全的工具了。 目前各种 CMS 算是在通用 CRUD 这方面做的还算好的,但是 CMS 的用途也没你想得那么通用不是吗 |
24
Jooooooooo 2021-07-09 23:55:52 +08:00
有啊
脚手架已经够完善了 |
25
yellowV2ex 2021-07-10 00:08:17 +08:00
十几年前搞过一个生成 PHP 的东西,填几个表和数据库字段就自动生成 sql,管理后台和 api 接口以及前端的请求,想不到这么多年了,还没有傻瓜工具出来,是后端人员太便宜了还是需求不够多?
|
26
snw 2021-07-10 00:33:21 +08:00 via Android
企业的 ERP 等系统大部分就是 CRUD,但你看 SAP 、Oracle 做这么多年了做得那么复杂都没有到终点,说到底还是因为业务需求太多样,并没有通用解决方案。
|
27
IvanLi127 2021-07-10 00:42:58 +08:00 via Android 1
等所有产品都是程序员转行时 可能有希望
|
28
levelworm 2021-07-10 03:30:41 +08:00
基本上每家大公司内部应该都有点自己搭的脚手架。对于程序员来说,难道不是应该期待自己做脚手架吗?
|
29
tinywhale 2021-07-10 04:13:46 +08:00
世界上建了那么多房子,为什么建房子还那么麻烦。
|
30
zeni123 2021-07-10 04:15:06 +08:00
计算机连洗碗都做不了。。。
|
31
James369 2021-07-10 09:22:45 +08:00
这样不好,世界要多样化,大家都有机会
|
32
usw 2021-07-10 10:34:55 +08:00
打疫苗别人问你第一针什么时候打的,还得想一想呢
|
33
winglight2016 2021-07-10 11:05:30 +08:00
有很多 CRUD 框架,还能自动生成代码,我记得还有个框架是直接 Spring cloud 都用起来了,但是要是能够解决所有需求,那就只能期望强 AI 了
|
34
cmdOptionKana 2021-07-10 11:27:20 +08:00
关键不在于技术啊,而在于客户要五彩斑斓的黑。
客户提出的需求是千奇百怪的,永远能超出现有的套路。 |
35
DeWjjj 2021-07-10 11:49:55 +08:00
有啊,我平时自己就是这么干的。
txt 里面写上配置信息然后文件读取,转化成代码。 |
36
tq5124 2021-07-10 12:22:06 +08:00
二十年前你要做个简单系统,要自己手写数据库( txt 读取),web 服务器,用 c++来业务逻辑。现在就只需要 CRUD,难道不是已经是一种伟大的进步了嘛?
基本上现在各个组件(数据库,服务器框架,日志分析)都有各自的开源组件,CRUD 们要做的是根究需求把这些连起来 |
37
sobigfish 2021-07-10 12:40:14 +08:00
@wangxin13g 然鹅,你现在还能看到有的招聘通告里面有“要求”DW 的,太扯了。
|
38
opentrade 2021-07-10 13:03:28 +08:00
CRUD 下面可以是小家别院,也可以是星辰大海。
|
39
namelosw 2021-07-10 14:32:11 +08:00
简单地说其实是有很多纯 CRUD 系统的,比如给你的数据库客户端或者 CRUD 的 GraphQL,这类产品绝大部分问题是你想覆盖一部分逻辑进去就很恶心,特别是 UAC 等等。
假设考虑做一个内网不需要考虑安全的 admin 后台,前端直接发 SQL 到后端 eval,其实就是跳过 CRUD 了。问题就是考虑安全的时候,又不太好把后端的逻辑编译进 SQL 里,有存储过程,但是能力有限而且很恶心。这里面缺乏一种随意嵌入逻辑的「柔性」。 换句话说 CRUD 存在主要是因为我们用的语言和工具表现力不够抽象以解决 CRUD 问题,很多代码用能想出来但是用 Java 写不出来的。Fortran 没有二维数组,Cobol 没有函数,Go 没有泛型,很多东西缺了功能就会缺表现力。不只是编程语言,工具和系统也是,比如 MySQL 里不能随意嵌入 Java,Redis 只能嵌入 Lua 之类的。 表现力强的语言社区里,用户对表现力强的部分也不够信任,比如 Clojure 和 Elixir 社区对于宏的态度是「用宏的第一条规矩就是不用宏。能用函数就函数,不能用函数再用宏」。 不过也有一些被埋没的流派,其实感觉并没有真被规模化地探索过,拿宏作为例子,Paul Graham 说过他的代码 25% 都是宏(一般 Elixir 和 Clojure 程序能有 5%就很高了,很多人都完全不用),还有 Let Over Lambda 那本书里一些激进的双关等等。 有意思的是现在人们都在说 AI 写代码之类的,其实代码写代码最简形式早就有了,也就是宏,或者说 symbolic programming,一度被认为是编程界的下一个重心,结果随着上一波 AI 破产被遗忘了。 |
42
charlie21 2021-07-10 15:58:51 +08:00
为什么需要一个大而全的解决方案呢?你做 CRUD 老板没给你钱吗,你想想你拿了这个解决方案 老板也可以拿 然后你就被开除了,所以 你为什么想要一个大而全的解决方案呢?应该是你的老板想要一个大而全的解决方案,拿到之后方便开除你。
#程序员自杀行为日常 |
43
Building 2021-07-10 16:09:52 +08:00 via iPhone
这个问题就好像在问喜马拉雅为什么是世界最高峰一样。
|
44
charlie21 2021-07-10 16:13:11 +08:00
织袜机器的广泛运用成为了卢德运动的导火索。织袜机能高速的缝制袜子,但质量奇差、价格低廉,一下子冲击了市场,使得无数传统织袜厂纷纷倒闭,工人失业。工人们曾经呼吁工厂主不要使用织袜机,但收效甚微,于是展开了一场暴力运动,即为卢德运动
https://www.sohu.com/a/333582725_552814 |
45
acmore 2021-07-10 18:10:23 +08:00
“大而全” 很多时候都是缺点而非优点。
|
46
wellsc 2021-07-10 18:18:39 +08:00 via iPhone
@IgniteWhite 这种简称本来就没有先后顺序,没规定不让哈希冲突吧
|
48
Samuelcc 2021-07-10 20:57:15 +08:00 via Android
有句话是怎么说的,Generalization is generally wrong. 可能也适用于这种场景。
|
50
IgniteWhite 2021-07-10 21:55:28 +08:00
@wellsc
@Samuelcc 啊我就想介绍一下这个约定俗称的叫法,人们都这么说而已,不是什么规定。三楼给的维基百科里也讲了一些其他叫法: Other variations of CRUD include: CRUDL (create, read, update, delete, list) BREAD (browse, read, edit, add, delete) DAVE (delete, add, view, edit) CRAP (create, replicate, append, process) 既然有叫 bread 的,其实叫 curd 也合理,都是食物嘛。crud 和 crap 的叫法就是垃圾的意思,带有自黑。 |
51
monimonipo 2021-07-10 22:52:13 +08:00
快速配环境不是有 XAMP PHPSTUDY 之类吗,apche/nginx+php+mysql/mariadb+redis,啥都有;
你说的 UI 脚手架有一些 CMS 可以实现,wordpress,织梦等等,不需要你写一行代码,后台有可视化编辑器; 日志分析,性能警告的更多啊,宝塔之类,就不和你说 zabbix nagios prometheus 。 |
52
Mohanson 2021-07-10 23:11:07 +08:00
大而全的解决方案不就是招收职业的 CRUD Boy 吗(狗头
|
53
ChefIsAwesome 2021-07-10 23:40:01 +08:00
大而全的解决方案就是写代码。
|
54
alsotang 2021-07-10 23:44:05 +08:00
我觉得 ruby on rails 是的。
|
55
MarkLeeyun 2021-07-11 00:03:28 +08:00
@Building 为什么?
|
56
cedoo22 2021-07-11 00:32:39 +08:00
AI 要是能自己编程, 除非有一种模型能把所有需求 以及意外情况都能完美模拟出来, 但是人的行为 又不是什么事情都完全符合逻辑的,
所以,要完全控制细节 还是只能用代码来搞定, 越往后 编代码会变得越来越简单。 |
57
MintZX 2021-07-11 14:05:48 +08:00
不存在的,元素周期表上就 118 个元素,你给地球上所有物质套个模版出来。。
|
58
liuxingdeyu 2021-07-11 15:46:22 +08:00
程序怎么定义项目复杂度呢,做个 12306 和做个动物园电瓶车票调度本质上功能是一样的,但是实际上能一样吗。还有聊天,我们大学学 mfc 那会考试就让写一个局域网聊天工具,但是你看看微信,你再看看 qq
|
59
zhennann 2021-07-11 16:20:59 +08:00
从来没有一劳永逸的大而全的解决方案。但是如果仅仅停留在 CRUD 的层面,显然又不符合咱们程序员不断追求进步的气质
在业务系统中,CRUD 仅仅是数据管理的基础,在此基础上还需要考虑:菜单权限、数据权限、审批流、前端界面显示(兼容 mobile/pc )、消息推送、历史数据,等等。对于大多数业务系统而言,以上诸方面都有共性。能把这些共性部分抽象出来,提供统一的接口,同时也提供可扩展的机制,那么就可以极大的提升业务系统的开发效率了 强烈建议参考一下 NodeJS 全栈开源框架 CabloyJS,尝试着在 CRUD 的基础上前进了好几步,在线效果预览: https://test.cabloy.com/ |