Golang Go语言中的仓库模式,真的好吗?
Golang Go语言中的仓库模式,真的好吗?
虽然启用了 go mod,但是不像 Java 那样有一个非常强大的中央仓库 maven,版本迭代和可靠性都是有保障的
go 虽然可以从 github 上虽然可以直接拉包下来,但是因为有的作者没打 tag,拉取的版本号显示的非常奇怪
而且如果哪天某个 lib 的作者一不高兴删了自己的仓库,那要部署代码的时候,就两眼懵逼了
当然不好,从没见人说 go 的包管理好话
更多关于Golang Go语言中的仓库模式,真的好吗?的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
你看国内互联网大公司谁没有自建 maven 仓库?为什么?
如果是企业级项目一般不会依赖 github
你去看看 gopath 在 issue 上骂得多凶
1. 作为 maven 主库的缓存代理, 由于网络原因, maven 主库下载速度比较慢
2. 作为本地私有仓库, 公司的代码原则上不允许推到公共仓库. 就像有 GitHub 也要自建 gitlab 一样
上述原因没有一个是因为 maven 这种包管理方式有问题
中央仓库就不会删除包了吗?隔壁 NPM 的教训忘记了吗?
为什么有 go mod 还会有这种烦恼?其实一样可以自建中央仓库的呀
tag 都没有 搞不好哪天就没了的库你敢用么
没有绝对的好不好。
go1.13 会默认 go proxy https://proxy.golang.org/
你说的删除的问题,只要存过代码,可以起个新的 repo 后 go mod replace 解决
这个在前期技术调研的时候其实就可以避免,靠谱点的公司都不会用野鸡第三方项目的。
可以先 fork 下。
go 的包管理一塌糊涂
还好,和集中式仓库模式相比各有所长
企业项目会将依赖放入自己的 pkg 里吧,不会直接引用 github 等外部包,除了 go 官方包
删就删啊,只要你用过一次,你本机上就存了的,你可以另外开一个,传上去,然后在 go.mod 里写一行 replace
广泛使用的代码,肯定每个使用者机器上都存了的,想彻底删除,是不可能的,何必担心删库
另外还有代理,代理也会缓存代码,删库也未必影响
maven 叫“中央仓库”,那 github 为什么就不能叫“中央仓库”?
你可以 vendor,可以 fork,可以自建 git 服务,可以自建代理缓存,方式有很多。不要认为就只有一种模式。
NPM 那种管理一片混乱的所谓中央仓库是不能作数的
中央仓库存在的意义是信任和稳定,如果连这都不需要那你的确不需要中央仓库,但是中央仓库的存在为大量的人节约了时间和精力。不是每个人都愿意像你这样折腾的
分布式仓库就没有信任和稳定了? maven 就不会倒闭? npm 还被投过毒,中央仓库就一定稳定和值得信任,我认为是假命题。github 也没有浪费谁的时间精力吧?我用 github 做仓库也没有啥折腾的。
go 的仓库模式,就等于 git、hg 等版本管理工具的模式,你不习惯可以不用,但我们用得好好的。
中央仓库的信任问题怎么解决?上传了恶意包怎么办? npm 会出现的问题 maven 怎么保证不出现的?
在Golang(Go语言)中,仓库模式(Repository Pattern)作为一种常见的架构设计模式,确实有其独特的优势,但也需根据具体应用场景权衡其适用性。
仓库模式的核心是将数据访问逻辑(如CRUD操作)封装在一个单独的层中,使得业务逻辑层与数据访问层解耦。这种做法带来了几个好处:
- 提高代码的可维护性:数据访问逻辑集中管理,便于修改和测试。
- 增强代码的可测试性:通过接口定义仓库,可以方便地使用mock对象进行单元测试,避免直接依赖数据库。
- 促进业务逻辑清晰:业务逻辑层专注于业务规则的实现,不再关心数据如何存储和检索。
然而,仓库模式也可能引入一些额外的复杂性,特别是在项目初期,可能会觉得增加了一层不必要的抽象。此外,如果过度设计或使用不当,可能会导致代码冗余和性能下降。
因此,是否采用仓库模式,需要综合考虑项目的规模、团队的熟悉程度以及具体的业务需求。对于小型项目或快速迭代的产品,可能不需要立即引入这种设计模式。而对于大型、复杂或需要长期维护的项目,仓库模式则能提供更清晰的结构和更好的扩展性。
总之,仓库模式在Go语言中是有效的,但应根据实际情况灵活应用,以达到最佳的设计效果。