Golang Go语言中哪些大型项目正在使用 Echo 框架 想学习一下它们的项目结构

null
Golang Go语言中哪些大型项目正在使用 Echo 框架 想学习一下它们的项目结构

17 回复

go 的工程结构看这个就好了: https://github.com/golang-standards/project-layout

更多关于Golang Go语言中哪些大型项目正在使用 Echo 框架 想学习一下它们的项目结构的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


#1 这个结构好像不太适合 Web 项目

正好这两周都在研究 kratos 的项目结构，来吧，kratos-layout 整起。https://github.com/go-kratos/kratos-layout


又是一个受害者，早期被别人带跑偏了。。。

先看下 go 作者主力和一众人怎么喷这个项目早点纠正下姿势吧:joy:：
https://github.com/golang-standards/project-layout/issues/117

rcox 自己本来就爱喷，很多人喷的是这个名字误导人。这个只是从多个知名项目提取的一个总结结构，很具参考价值。就算是官方的也肯定不是一味的采取，参考后根据自己的需求调整才是最好。

这个项目的工程结构真的没什么可参考的。

然而实际工程里面这个项目结构挺好用，不管 rcox 喷还是不喷，适合的就是好的。实践里面我们很多工程都按这个目录来，也清晰明了没出现什么问题。

所以也不存在什么受害人，要我说盲目跟风 rcox 的才是受害人

#1 真不建议参考这个结构，槽点太多了
比如 cmd ，代指多个 main 入口，正常情况下这种颗粒太粗了，真正多个入口，更建议独立一个项目出来
比如 pkg ，代指可被引入的包，正常情况下可被引入的包，更建议也独立一个仓库，放在某一个项目的子目录下并不合适
比如 internal ，代指内部使用，更建议作为一个业务功能的子目录，作为数据定义等，内部使用，而不是直接暴露出来但是又不让引入，而且也不建议引入业务项目的子目录作为，参考上一条
其他没有业务代码的懒得说了，但是整体上来说，这个目录结构有点分层不清醒
老实说，简单的 mvc 加个 service 都比这样强

我们的项目：github.com/eduoj/backend ，3 万行代码，应该不算小项目

当然也算不上大


第一，这与跟风完全无关，我不是因为 rsc 开贴而跟风，我自己的工程结构都是自己设计。
既然说到跟风，你有没有思考过哪种人擅长跟风？自己的设计能力不足、缺少判断力的人，才经常跟风，工程结构这种事情涉及到一定的设计审美能力，但还不至于是难度很大的事情、也不至于太过影响工程效率，因为即使工程结构不漂亮、只要团队人员都熟悉后形成项目规范、那项目就能足够有效推进了。各种语言，项目结构多了去了，对于工程效率，通常是约定大于配置
你觉得这个好，大概率是因为你在自己的 go 项目积累初期阶段没有自己花心思去认真思考和设计工程结构，刚好又看到有可以参考的就直接拿来用、并且用习惯了，用习惯之后其实就无所谓了。所谓的实践里你们很多工程按这个目录来也清晰明了没出什么问题，但你有没有想过其实如果你早期是参考了一个其他模板，习惯后也照样清晰没什么问题？因为这中工程结构，只是目录结构而已，并不是那些决定项目生死的算法、数据结构、框架基础设施实现质量最主要因素，比如高并发高性能，一些算法、数据结构、系统编程能力直接决定了项目能否满足性能要求（尤其是对单点性能要求很高、不是无状态那种随便加硬件就能解决的类型）。所以你说这个模板你们很多项目用着没什么问题——这说法没毛病，确实没什么问题，但这并不能证明它真的就是好，并不是所有人都能够像你们一样能够轻易接受别人的某种设计审美，而且至少我接触的高阶开发人员里，不喜欢这个模板的人居多

第二，先不论这个模板好不好，作者自己冠以 standard 。项目种类很多，你要是类似 spring 或者 larval 或者什么框架之类的，自带工程结构作为自己框架的 standard 那无话可说，然而你不是框架、只是个目录结构，跟中文那些文档类的 star 项目没什么本质区别。并且冠以 go 语言本身的 standard ，作者要脸吗？说句不好听的，这叫鸠占鹊巢、沽名钓誉，个人觉得这不仅不严谨，而且不道德

第三，说说这个模板到底好不好。不同的项目类型有不同的模块、组件需要，对应不同的目录结构通常是项目自家人员设计更贴合实际审美，通常大家倒是有一个共识——对于很多不同场景时没有银弹，既然没有银弹，即使是再去研究并且列举它哪里不好都是对时间的浪费。所以这个作者搞一个自以为通用适合所有项目类型的模板（只是目录结构），我觉得说他是招摇撞骗也不为过

我也来学习一下子！

同感, 这个项目的结构其实并不是万能的, 而且槽点也挺多, 你说的那几个槽点我也感同身受. 大家项目各自的规模大小, 实际情况并不相同, 只能说这个项目提供了一种参考, 而且多是命名上的参考, 没有必要全盘接受.

rsc 没出这个回应前, 之前的项目组里面要求即使项目没有 web, 也没有脚本, 只是一个简单的命令行二进制工具, 也没有依赖任何外部包, 源码里面也要带上 web, scripts, vendor, deployments 等目录, 问了就说这是 Go 官方的 standard, 有一种类似宗教里面那种原教旨狂热. 自从出了这个回应后, 技术总监被打脸了, 再也没有继续坚持.

适合自己的就是最好的，也许某一种你认为“不好的”，比如关于 /pkg 的争论，当大家都这么做的时候，其实就是一种标准了。

来自 rsc 的回复。

There are two problems with this GitHub repo:

it claims to host Go standards and does not, in the sense that these are in no way official standards
the project-layout standard it puts forth is far too complex and not a standard
Regarding “why not tell us the standard Go project layout and we’ll update the doc?”, that only addresses point 2. If there really were standards, they would be in the main Go project doc tree. The standard for project layout would also be a lot shorter. I appreciate your trying to provide a useful resource, but calling it ‘golang-standards’ is claiming more than it is.

But for the record, the minimal standard layout for an importable Go repo is really:

Put a LICENSE file in your root
Put a go.mod file in your root
Put Go code in your repo, in the root or organized into a directory tree as you see fit
That’s it. That’s the “standard”.

In particular:

It is not required to put commands in cmd/.
It is not required to put packages in pkg/.
It is not required to put web stuff in web/.
It is not required to put APIs in api/.
It is not required to put web stuff in web/.
It is not required to put configurations in configs/.
It is not required to put systemd scripts in init/.
It is not required to put shell scripts in scripts/.
It is not required to put Docker files in build/package/.
It is not required to put CI configs in build/ci/.
It is not required to put deployment configs in deployments/.
It is not required to put test support in test/.
It is not required to put documentation in docs/.
It is not required to put supporting tools in tools/.
It is not required to put examples in examples/.
It is not required to put third_party code in third_party/.
It is not required to put git hooks in githooks/
It is not required to put static assets in assets/.
It is not required to put website data in website/.

The importable golang.org/x repos break every one of these “rules”.

你们说了这么多,能不能回答一下问题呀

在Golang（Go语言）中，Echo框架以其高性能、简洁和灵活的特性，被多个大型项目所采用。以下是一些使用Echo框架的项目及其项目结构方面的学习建议：

使用Echo框架的大型项目

虽然具体的大型项目名称可能因各种因素（如项目保密性、使用频率变化等）而难以一一列举，但Echo框架在社区中拥有广泛的影响力，被众多开发者用于构建高性能的Web应用程序。这些项目通常涵盖了Web开发、云计算、API服务等多个领域。

项目结构学习建议

  1. 参考官方文档和示例：Echo框架的官方文档提供了丰富的示例和最佳实践，是学习项目结构的绝佳起点。
  2. 分析开源项目：在GitHub等平台上搜索使用Echo框架的开源项目，并分析它们的项目结构。这些项目通常具有良好的代码组织和文档，有助于理解Echo框架在实际项目中的应用。
  3. 模块化设计：学习如何将项目拆分为不同的模块，如控制器、模型、服务层等，以提高代码的可维护性和可扩展性。
  4. 中间件和路由配置：了解Echo框架中的中间件和路由配置，这些特性使得Echo框架能够灵活处理各种Web请求和响应。

通过以上方式，你可以深入了解Echo框架在大型项目中的应用，并学习到实用的项目结构设计方法。

回到顶部