看到这标题我真是一口可乐喷出来了.
go 的出现本来就是为了规避这些复杂的要死的设计模式.
大道至简.
结果你把依赖注入都搬出来了.
那你为什么不直接用 ASP.NET Core 算了.

@ytll21 当然, 如果系统没有这么强的一致性要求, 用存储过程就纯属是给自己找不自在.

@ytll21 不用存储过程, 用程序处理的话, 终归会有反复与数据库交互的过程. 十次八次的还好, 像某些银行那样的系统, 一笔交易涉及各种跨库跨表查询几十个 (尤其有不少还涉及到本地服务, 如水电气缴费, 地方分行/支行企业合作业务, 自动扣费业务/罚款等), 反复与数据库交互的这个通讯的成本是很高的. 一般来说银行的各种交易必须在几百毫秒之内结束, 而且不可以出现单据不一致的情况. 这与互联网企业的最终一致性要求是不一样的. 银行, 电信系统之类的, 要求的都是实时强一致性. 在这种需求之下, 存储过程是最好的. 至于研发难度, 反正也不是老板需要面对的事情. 有难度你们研发慢慢啃去呗.

@aureole999 银行的账务逻辑比证券复杂多了.

@imnpc 不一定 好多 30 多岁的老开发, 对数据库的理解可能比 DBA 还深刻.

@tanhui2333 这个不是开历史倒车. 是有些场景下只有存储过程合适. 在大并发高一致性高实时性的场景. 比如银行. 你不可能说这边支付完了过了好几秒余额才减掉吧.

看情况. 对于互联网企业来说, 存储过程本身就是没必要的. 互联网企业本身业务非常简单, 几乎无外乎 CURD.
但是对于 SAP, 用友, 久其, 任我行那些 ERP 系统, 以及四通一达的那些 WMS 系统来说, 存储过程就是解决复杂需求的利器. 哦对, 也包括电信运营商与银行. 它们的存储过程更加复杂, 但存储过程对他们来说也往往是必然的选择.


业务逻辑越是复杂, 存储过程的就越是有存在的必要.

哦对, 铁路的 TRS 后面的业务逻辑全都是存储过程.

如果是做项目那无所谓. 如果是做产品, 国内的这些组件一律慎重考虑. 能不用就不用.

@woniu7 有很大意义. 代码写法越优雅, 后期维护难度越小.
那种一层套一层
{
{
{
{
{
{
{

的代码是最难以维护的.

所以为什么说 golang 不适合写业务呢. 不是开玩笑的. 这种表达能力极其羸弱的编程语言, 就很适合写 infr, 比如写消息队列组件, 写个 Redis 替代品, 或者写编译器. 说白了就是适合写各种重算法轻逻辑的程序. 但是如果去写业务逻辑, 尤其是那种极其复杂, 不正交的业务逻辑那就是灾难.

能支持动态任务 / 延迟 / 定时 / 状态回写不?
能保证在一秒十万个任务同时执行的情况下每个任务都能精确到秒么?
能不能提供 C++ / Java / .NET / Python / Golang SDK ?

期待一下, 我们 .NET 开发们苦 Hangfire / QuartZ 那两个屌逼东西好久了 (✧∀✧)

这玩意就跟折腾 Android 刷机一样. 趁年轻折腾吧. 等到了三十多岁你就折腾不动了, 还是找个稳定靠谱的 Windows 养老.

基本上停留在 infer 层面. 做底层, 写运维工具. 而且我们这也是要求不能只会 go. 还得会 C#. 平时 C# CURD, 必要时候用 go 写点 ops 的东西.

@isnullstring 是的. 有的岗位, 招聘者自己都已经去跑外卖了, 招聘的公司都已经倒闭了, 但是招聘的帖子还挂在那时不时的还会跳到首页来诈一下尸. 我以前也向他们提过建议, 增加个筛选功能, 应聘者可以筛选招聘者必须是多久时间之内在线的, 但是他们就是死活不肯加.

实际上现在去 BOSS 上看, 几乎都是招主播/虚拟主播的 MCN 机构, 招开发的真不多了. 好多岗位都是挂在那, 点进去一看, 一周前活跃, 一个月前活跃, 一年前活跃... 再用天眼查查一下关联公司...... 注销, 吊销, 失信被执行人, 协议解散, 破产案件...... 回头看知乎上的回答, 似乎一切又在歌舞升平, 各种打工人眼里的老板们一个个儿开跑车住别墅喝洋酒泡二奶好不自在... 也不知道到底哪边才是真的...

@Adamo 得了吧, 这就是典型的画大饼. 他承诺创业失败退还本金. 真创业失败了, 到时候他自己花呗借呗微粒贷美团京东支付宝一堆外加一堆银行贷款还不上, 还给你退本金? 到时候怕不是问就是会还, 再问就是已读不回了.

现在时局动荡, 这个节骨眼最稳妥的就是找个盈利情况好的, 稳定的企业养老.