手把手带你写一个 Web 框架
叶剑峰
腾讯高级工程师,前滴滴技术专家
22731 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 42 讲
特别放送 (1讲)
手把手带你写一个 Web 框架
15
15
1.0x
00:00/00:00
登录|注册

12|结构:如何系统设计框架的整体目录?

思考题
总结
默认目录的实现
定义默认目录结构
如何设计
框架和业务区分
结构:如何系统设计框架的整体目录

该思维导图由 AI 生成,仅供参考

你好,我是轩脉刃。
到现在,我们已经将 Gin 集成到框架 hade 中,同时又引入了服务容器和服务提供者,明确框架的核心思想是面向服务编程,一切皆服务,所有服务都是基于协议。后续也会以服务的形式,封装一个个的服务,让我们的框架越来越丰富。
但是服务文件代码应该存放在哪里呢?这是我们会最先遇到的问题。业务的目录结构是否应该有规范,应该如何规范?所以今天这节课我们就来讨论这个问题,从系统的角度考虑框架的整体目录设计。

框架和业务区分

有人可能会问了,我们写的不是一个 Web 框架么,为什么要规范业务的目录结构?像 Gin 框架,就没有规范业务应用的目录结构,业务方根据自己的需要,想怎么组织业务目录就怎么组织,不好么?作为一个框架,想规范业务的目录结构,这样做是不是有点越俎代庖?
这个问题其实很有意义,我们需要搞清楚目录结构到底是用来干什么的。
业务代码的目录结构是一种工程化的规范。所谓工程化,简单来说就是希望不管是谁,在一个工程项目中,都按照一种做法来完成某个事情。而目录结构,就是项目工程化的一个起点。
在一个公司或者一个部门中,如果有架构团队,基本上要做的第一个事情就是,规范公司或者部门的代码目录结构。整体目录结构不仅仅代表着分层、归纳,也包含着很多架构的思想。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文介绍了如何从框架层面规范业务的目录结构,强调了目录结构作为工程化规范的重要性。作者首先讨论了框架和业务目录结构的区分,强调了目录结构对于框架实际应用和工程化使用的关键性。接着,文章提出了如何设计目录结构,强调了面向接口编程的思想,并定义了应用目录服务的接口协议。在定义默认目录结构方面,作者参考了市面上的优秀框架,并详细解释了每个子目录的功能和划分。文章还介绍了如何通过服务容器来获取目录结构服务实例,并实现了默认目录结构的方法。最后,文章强调了提供默认目录结构的重要性,以及在实际开发中可能需要迭代修改目录结构。总体而言,本文强调了目录结构的重要性,以及如何通过面向接口编程和参考优秀框架来设计和实现框架的整体目录结构。文章内容涵盖了框架设计的精妙之处,展示了作者对框架设计的深入思考和优秀设计感。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《手把手带你写一个 Web 框架》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(12)

  • 最新
  • 精选
  • 宙斯
    之前见php框架中yii2在app下有module这一层,对于modules业务划分我见过mvc方式划分。 在其他框架上也见过DDD方式。 MVC方式如下: 目录结构类似下面 config controller model view --modules ----app1 ------config ------controller --------aController.php ------model --------aModel.php ------app1Module.php ----app2 -------------------------- DDD方式 apps --app1 ----backend ------bin --------controller ------config ------web --------controller --app2 modules --xapp1 ----application ------aa.php ----domain ------da.php ----infrastructure ------ia.php --xapp2 --xapp3

    作者回复: 赞👍

    2021-10-24
    2
  • 芒果少侠
    首先看这节课的时候,我是感觉有点抽象和难以理解的,烦请老师指正一下。这个app服务,是不是就相当于一个业务服务(基于hade框架完成)? 关于思考题:一般来说,我这边工作上是这样的: DDD是在类似本文的app这一维度划分的,比如说我有多个服务app1,app2,app3。每个服务里又通过service/cmd/dao/model等分层次划分目录架构。

    作者回复: 是的,app服务定义的意思就是,你要启动一个应用来使用hade框架后续的一些功能,那么这个应用的这些目录你要安排一下具体实现,后续我框架的所有功能都会在这些目录里面操作

    2021-10-13
    2
    1
  • 老师我感觉laravel的 model就类似充血模型 不知道我有没有理解错

    作者回复: 其实model这一层一直有个讨论,就是胖model还是瘦model,model里面是不是应该放一些业务逻辑。

    2021-12-08
  • 那么老师是不是会提供一个 new hade 这种玩意 生成模板来用 ,其实在我心里我一直认为框架就是帮我规定好了一些最小目录范围,我可以没有什么心智负担的对于工程目录的规划,但是用gin让我感觉就是一个包,我引入gin可以自己定义各种工程化规范。两者都有好处 但是对于我这种没有什么架构经验的来说 我更喜欢laravel这种 (虽然我也很想有架构经验)

    作者回复: 嗯,后面有提供这个new hade,那个实现的设计还有点意思,慢慢看

    2021-12-08
    2
  • 对于一个用了很久的laravel的我来说 看起来太熟悉太亲切

    作者回复: 是的。。

    2021-12-08
  • qinsi
    老师能不能举个例子,App服务会有哪些不同的实现?常见的服务比如日志、数据库、消息队列之类的,很容易理解会有不同的实现。那App服务不同的实现是怎么样的? 光看目前App服务的接口的话,似乎都是在规定路径?那么不同的实现就是路径可能会不一样?可能换个名字叫ProjectLayout服务更能体现其用途?

    作者回复: 比如我想把runtimefolder改个名字,重新定义一个app服务就行了

    2021-10-13
    3
  • 小马🐎
    站在使用者的角度来看 这种设计业务目录的方案非常没用,除非特别规定死,业务目录必须是什么样子的,不然根本不会去用,除非是刚出道的菜鸟,只能按部就班的使用。
    2022-12-12归属地:上海
  • Geek_065895
    感觉真的不适应
    2022-03-09
  • yiyi
    叶老师,发现一个bug,多次调用HadeApp.BaseFolder()方法,若是没有在初始化的时候指定baseFolder这个字段,第二次调用时会出现panic,原因是flag多次解析同一个字段引发的flag redefined。解决方法:第一次调用获取到BaseFolder后缓存这个字段。不知道这样行不行。
    2022-02-14
    2
  • peterszhou
    这个好像跟传统的go项目布局不大一样,一般是pkg1、pkg2、command、internal这样的布局
    2022-01-13
    1
收起评论
显示
设置
留言
12
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部