• 请不要在回答技术问题时复制粘贴 AI 生成的内容
heheda11
V2EX  ›  程序员

计算机经历几十年 CURD,难道没有一个大而全的解决方案吗?

  •  1
     
  •   heheda11 · Jul 9, 2021 · 8913 views
    This topic created in 1946 days ago, the information mentioned may be changed or developed.

    一套告诉你 CURD 操作就没有?

    比如 超强 UI 脚手架。。 从 ES Redis MYSQL 一些列中间件 一键勾选自动生成,所有基本库操作

    从追踪连到日志分析,性能警告

    就没有这样的东西吗?

    59 replies  •  2021-07-11 16:20:59 +08:00
    nowheremee
    nowheremee
    Jul 9, 2021
    1
    没有银弹。
    fishily1993
    fishily1993
    Jul 9, 2021❤️11
    2
    我很感激没有这种东西,要不然我就只能去要饭了
    FurN1
    FurN1
    Jul 9, 2021 via iPhone❤️20
    3
    C R U D

    https://en.m.wikipedia.org/wiki/Create,_read,_update_and_delete

    不是 curd 。curd 是凝乳。取 crud 因为 crud 这个词本身有渣渣的意思。造句:我是一个只会 CRUD 的 crud
    heheda11
    heheda11
    OP
    Jul 9, 2021
    4
    @IgniteWhite 谢谢提醒
    wangxin13g
    wangxin13g
    Jul 9, 2021❤️4
    5
    上一个想这么玩的 DW 坟头草已经三尺深了。
    shaojz2005
    shaojz2005
    Jul 9, 2021
    6
    低代码平台就是尝试解决这个问题嘛
    bthulu
    bthulu
    Jul 9, 2021
    7
    光一个好用的 orm 框架, 没有真泛型的语言都实现不了.
    polyang
    polyang
    Jul 9, 2021
    8
    还好没有这东西,不然还要我们干嘛
    GlobalNPC
    GlobalNPC
    Jul 9, 2021
    9
    不同的业务有不同的需求,不同的领导有不同的偏好
    dji38838c
    dji38838c
    Jul 9, 2021
    10
    一共才四个字母,天天都要做,顺序都还说不对
    可见还是很有必要继续下去。
    pkoukk
    pkoukk
    Jul 9, 2021
    11
    我在家做饭的时候也感叹于做饭的繁琐,为啥没有省力的解决方案。
    目前的方案再方便,洗菜、切菜、炒菜、洗碗也是分开的。
    3dwelcome
    3dwelcome
    Jul 9, 2021❤️1
    12
    @wangxin13g DW 一开始方向就错了,Web 工具就不应该走传统客户端设计的路线。

    就应该在线设计,类似 figma 那种可见即可得,模板式傻瓜开发。

    然后帮客户自动托管网站,托管数据库,托管 CMS 后台。DW 如果起初能对接在线数据库,也不会死那么惨了。

    要想把 CRUD boys 干掉,就必须把数据库和后台一锅端。
    maemual
    maemual
    Jul 9, 2021
    13
    单纯 CRUD 可以搞啊。但是有什么用的。哪家需求这么弱呢。
    msg7086
    msg7086
    Jul 9, 2021 via Android
    14
    只是 crud 的话 rails 还可以吧,再多了就不清楚了。
    walpurgis
    walpurgis
    Jul 9, 2021
    15
    通用解决方案的整合速度赶不上底层组件的迭代吧,看现在招聘市场主流的 Springboot Vue React,出现也就 10 年不到,被市场认可也就 5 年左右,哪有几十年
    这两年迭代速度稍微放缓,低代码平台概念又开始火了,我寻思这不都以前玩剩的,只不过用了新的基础技术套个新名词
    NewYear
    NewYear
    Jul 9, 2021
    16
    @maemual
    OA 系统啊,企业里各种表单,需求非常大,快速设计界面,权限(分字段)、审批流、报表、字段运算(公式)、表单关联和回写数据、消息推送……
    morty0
    morty0
    Jul 9, 2021❤️1
    17
    @bthulu go 表示很淦
    DoctorCat
    DoctorCat
    Jul 9, 2021
    18
    桌面软件开发时代,RAD 开发的意思。但是 VB 与 Delphi 也凉凉的,都是换汤不换药。
    zzyphp111
    zzyphp111
    Jul 9, 2021
    19
    我记得当年织梦系统就是这样的,完全不需要 crud,全都是 ui 操作,那还是 2010 年....
    c88155745
    c88155745
    Jul 9, 2021
    20
    你想失业,还是想更内卷呢。
    littlewing
    littlewing
    Jul 9, 2021
    21
    小网站和系统有低代码可以尝试,大的系统,CRUD 只占很小一部分
    JerryCha
    JerryCha
    Jul 9, 2021
    22
    C: 指 A 部门 B 角色 C 岗位具有 D 资质但不是 E 编制的人可以向 F 部门 G 角色 H 岗位且与 E 编制下 I 不存在利益关系的员工提起一个 create 操作申请,批准后交由 J 部门随机指定一名具有 K 权限的人进行创建。
    BeautifulSoap
    BeautifulSoap
    Jul 9, 2021 via iPhone❤️2
    23
    程序员都自嘲说只写 CRUD,但实际上想想 CRUD 是干嘛的?是用来完成业务逻辑的。

    业务逻辑代表着现实世界中千变万化无比复杂的需求,业务逻辑就是现实,那么请问世上真的能有这么一个模型或框架可以覆盖绝大多数的业务逻辑吗?答案肯定是不存在的,世上没有银弹。即便是 CRUD 根据不同的业务需求,实现方式都会有巨大的变化,自然就不存在什么一劳永逸大而全的工具了。
    目前各种 CMS 算是在通用 CRUD 这方面做的还算好的,但是 CMS 的用途也没你想得那么通用不是吗
    Jooooooooo
    Jooooooooo
    Jul 9, 2021
    24
    有啊

    脚手架已经够完善了
    yellowV2ex
    yellowV2ex
    Jul 10, 2021
    25
    十几年前搞过一个生成 PHP 的东西,填几个表和数据库字段就自动生成 sql,管理后台和 api 接口以及前端的请求,想不到这么多年了,还没有傻瓜工具出来,是后端人员太便宜了还是需求不够多?
    snw
    snw
    Jul 10, 2021 via Android
    26
    企业的 ERP 等系统大部分就是 CRUD,但你看 SAP 、Oracle 做这么多年了做得那么复杂都没有到终点,说到底还是因为业务需求太多样,并没有通用解决方案。
    IvanLi127
    IvanLi127
    Jul 10, 2021 via Android❤️1
    27
    等所有产品都是程序员转行时 可能有希望
    levelworm
    levelworm
    Jul 10, 2021
    28
    基本上每家大公司内部应该都有点自己搭的脚手架。对于程序员来说,难道不是应该期待自己做脚手架吗?
    tinywhale
    tinywhale
    Jul 10, 2021
    29
    世界上建了那么多房子,为什么建房子还那么麻烦。
    zeni123
    zeni123
    Jul 10, 2021
    30
    计算机连洗碗都做不了。。。
    James369
    James369
    Jul 10, 2021
    31
    这样不好,世界要多样化,大家都有机会
    usw
    usw
    Jul 10, 2021
    32
    打疫苗别人问你第一针什么时候打的,还得想一想呢
    winglight2016
    winglight2016
    Jul 10, 2021
    33
    有很多 CRUD 框架,还能自动生成代码,我记得还有个框架是直接 Spring cloud 都用起来了,但是要是能够解决所有需求,那就只能期望强 AI 了
    QingXuJiaZhi
    QingXuJiaZhi
    Jul 10, 2021
    34
    关键不在于技术啊,而在于客户要五彩斑斓的黑。

    客户提出的需求是千奇百怪的,永远能超出现有的套路。
    DeWjjj
    DeWjjj
    PRO
    Jul 10, 2021
    35
    有啊,我平时自己就是这么干的。
    txt 里面写上配置信息然后文件读取,转化成代码。
    tq5124
    tq5124
    Jul 10, 2021
    36
    二十年前你要做个简单系统,要自己手写数据库( txt 读取),web 服务器,用 c++来业务逻辑。现在就只需要 CRUD,难道不是已经是一种伟大的进步了嘛?

    基本上现在各个组件(数据库,服务器框架,日志分析)都有各自的开源组件,CRUD 们要做的是根究需求把这些连起来
    run2
    run2
    Jul 10, 2021
    37
    @wangxin13g 然鹅,你现在还能看到有的招聘通告里面有“要求”DW 的,太扯了。
    opentrade
    opentrade
    Jul 10, 2021
    38
    CRUD 下面可以是小家别院,也可以是星辰大海。
    namelosw
    namelosw
    Jul 10, 2021
    39
    简单地说其实是有很多纯 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 破产被遗忘了。
    akira
    akira
    Jul 10, 2021
    40
    @namelosw 我们 20 年前就已经在期待 ai 编程的到来了
    holulu
    holulu
    Jul 10, 2021
    41
    charlie21
    charlie21
    Jul 10, 2021
    42
    为什么需要一个大而全的解决方案呢?你做 CRUD 老板没给你钱吗,你想想你拿了这个解决方案 老板也可以拿 然后你就被开除了,所以 你为什么想要一个大而全的解决方案呢?应该是你的老板想要一个大而全的解决方案,拿到之后方便开除你。

    #程序员自杀行为日常
    Building
    Building
    Jul 10, 2021 via iPhone
    43
    这个问题就好像在问喜马拉雅为什么是世界最高峰一样。
    charlie21
    charlie21
    Jul 10, 2021
    44
    织袜机器的广泛运用成为了卢德运动的导火索。织袜机能高速的缝制袜子,但质量奇差、价格低廉,一下子冲击了市场,使得无数传统织袜厂纷纷倒闭,工人失业。工人们曾经呼吁工厂主不要使用织袜机,但收效甚微,于是展开了一场暴力运动,即为卢德运动
    https://www.sohu.com/a/333582725_552814
    acmore
    acmore
    Jul 10, 2021
    45
    “大而全” 很多时候都是缺点而非优点。
    wellsc
    wellsc
    Jul 10, 2021 via iPhone
    46
    @IgniteWhite 这种简称本来就没有先后顺序,没规定不让哈希冲突吧
    zpxshl
    zpxshl
    Jul 10, 2021 via Android
    47
    @charlie21 历史的进展是无法抵挡的。
    Samuelcc
    Samuelcc
    Jul 10, 2021 via Android
    48
    有句话是怎么说的,Generalization is generally wrong. 可能也适用于这种场景。
    Samuelcc
    Samuelcc
    Jul 10, 2021 via Android
    49
    @wellsc 他应该意思是这个缩写有个双关意,所以顺序是有意义的。
    FurN1
    FurN1
    Jul 10, 2021
    50
    @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 的叫法就是垃圾的意思,带有自黑。
    monimonipo
    monimonipo
    Jul 10, 2021
    51
    快速配环境不是有 XAMP PHPSTUDY 之类吗,apche/nginx+php+mysql/mariadb+redis,啥都有;
    你说的 UI 脚手架有一些 CMS 可以实现,wordpress,织梦等等,不需要你写一行代码,后台有可视化编辑器;
    日志分析,性能警告的更多啊,宝塔之类,就不和你说 zabbix nagios prometheus 。
    Mohanson
    Mohanson
    Jul 10, 2021
    52
    大而全的解决方案不就是招收职业的 CRUD Boy 吗(狗头
    ChefIsAwesome
    ChefIsAwesome
    Jul 10, 2021
    53
    大而全的解决方案就是写代码。
    alsotang
    alsotang
    Jul 10, 2021
    54
    我觉得 ruby on rails 是的。
    MarkLeeyun
    MarkLeeyun
    Jul 11, 2021
    55
    @Building 为什么?
    dr1q65MfKFKHnJr6
    dr1q65MfKFKHnJr6
    Jul 11, 2021
    56
    AI 要是能自己编程, 除非有一种模型能把所有需求 以及意外情况都能完美模拟出来, 但是人的行为 又不是什么事情都完全符合逻辑的,
    所以,要完全控制细节 还是只能用代码来搞定, 越往后 编代码会变得越来越简单。
    MintZX
    MintZX
    Jul 11, 2021
    57
    不存在的,元素周期表上就 118 个元素,你给地球上所有物质套个模版出来。。
    liuxingdeyu
    liuxingdeyu
    Jul 11, 2021
    58
    程序怎么定义项目复杂度呢,做个 12306 和做个动物园电瓶车票调度本质上功能是一样的,但是实际上能一样吗。还有聊天,我们大学学 mfc 那会考试就让写一个局域网聊天工具,但是你看看微信,你再看看 qq
    zhennann
    zhennann
    Jul 11, 2021
    59
    从来没有一劳永逸的大而全的解决方案。但是如果仅仅停留在 CRUD 的层面,显然又不符合咱们程序员不断追求进步的气质
    在业务系统中,CRUD 仅仅是数据管理的基础,在此基础上还需要考虑:菜单权限、数据权限、审批流、前端界面显示(兼容 mobile/pc )、消息推送、历史数据,等等。对于大多数业务系统而言,以上诸方面都有共性。能把这些共性部分抽象出来,提供统一的接口,同时也提供可扩展的机制,那么就可以极大的提升业务系统的开发效率了

    强烈建议参考一下 NodeJS 全栈开源框架 CabloyJS,尝试着在 CRUD 的基础上前进了好几步,在线效果预览: https://test.cabloy.com/
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Privacy   ·   Solana   ·   1603 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 138ms · UTC 16:29 · PVG 00:29 · LAX 08:29 · JFK 11:29
    ♥ Do have faith in what you're doing.