徐昊 · TDD 项目实战 70 讲
徐昊
Thoughtworks 中国区 CTO
18159 人已学习
新⼈⾸单¥98
登录后,你可以任选4讲全文学习
课程目录
已完结/共 88 讲
实战项目二|RESTful开发框架:依赖注入容器 (24讲)
实战项目三|RESTful Web Services (44讲)
徐昊 · TDD 项目实战 70 讲
15
15
1.0x
00:00/00:00
登录|注册

37|RESTful Web Services(1):明确架构愿景与架构组件间的交互

你好,我是徐昊。从今天开始,我们就来使用 TDD 的方式实现 RESTful Web Services。
在上节课,我们展示了需要完成的几大功能块。我们很容易可以发现,RESTful Web Services 需要多模块协同完成。而不是像 DI Container 那样,可以从单一模块入手,在完成几个功能之后再进行重构。
那么我们可以先简单地规划一下架构愿景(Architecture Vision),以简化后续的工作。

规划架构愿景

首先,我们需要明确的是,我们将以 Servlet 的方式来实现 RESTful Web Services 框架。也就是说,我们将提供一个 Servlet 作为主入口,在其中完成对资源对象(Resources)的派分,并根据不同的超媒体选择对应的 reader 和 writer 进行输入输出处理。大致结构如下图所示:
然而仅仅如此,还不足以让我们顺滑地进入伦敦学派的流程(如果你足够自信,已经可以开始经典学派 TDD 了),我们需要进一步细化 ResourceServlet 中的组件与交互:
如上图所示,为大致的组件划分:
ResourceDispatcher 管理所有的 Root Resource,并根据 Root Resource 的标注形成路由表。它可以根据路由表,生产对应的 ResourceLocator。
ResourceLocator 表示与 URI 中某一段相匹配的资源方法(Resource Method),并负责调用它。
ResourceContext 表示 Resource 上下文,包含所有可注入的组件(通过 @Context 标注)。
BodyReader 聚合了所有的 MessageBodyReader,可以根据所需的类型,从 HttpServletRequest 中读取对象。
BodyWriter 聚合了所有的 MessageBodyWriter,可根据提供的类型,将信息写回到 HttpServletResponse 中。
ExceptionMapping 聚合了所有的 ExceptionMapper,可根据提供的异常,将信息写回到 HttpServletResponse 中。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文介绍了使用TDD的方式实现RESTful Web Services的架构愿景和架构组件间的交互。作者首先明确了以Servlet的方式实现RESTful Web Services框架,并规划了架构愿景,包括ResourceDispatcher、ResourceLocator、ResourceContext、BodyReader、BodyWriter和ExceptionMapping等组件。接着,作者详细阐述了这些组件之间的交互过程,并提出了通过经验设计、定向重构和Spike等方法来明确架构组件间的交互。最后,作者提出了两个思考题,引导读者思考如何调整架构愿景以及学习的收获。本文通过清晰的架构设计和交互过程,为读者提供了实现RESTful Web Services的指导和思考方向。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《徐昊 · TDD 项目实战 70 讲》
新⼈⾸单¥98
立即购买
登录 后留言

全部留言(6)

  • 最新
  • 精选
  • 张铁林
    https://github.com/vfbiby/tdd-restful 开始提交作业,这次把中间记的操作步骤一起放在项目doc下,还有小步提交,尽量,把每一个改变都提交上来,然后,每一章完成时,再做一个大提交。可以check到小提交处来练习。

    编辑回复: 可以,小步提交这个方法不错!

    2022-06-17
  • 人间四月天
    非常喜欢这个spike方法,在产品需求领域,叫做mvp最小可行产品,这个应该叫做最小可行设计,对于复杂需求,需求不清晰,或者复杂设计,通过这个方法验证架构愿景的可行性非常好,也能增强前期架构规划的信心。
    2022-06-02
    5
  • Geek_dcb102
    spike的过程: 1. spike过程 需要能够快速反馈结果 所以建议从一个开始可运行的小型框架 逐步替换成自己的代码 2. spike中 是需要自己认为的组件 尤其是大的组件 都全员参与的 确定组件之间的关系是否合理 3. spike中 需要参考现成的规约api 让组件更内聚合理 保证后续的复杂升级的可能性 也可以更好的观察组件的理解和划分是否合理.防止因为一开始的用例简单 造成很多组件相互耦合 职责不清 没有复杂升级的方向 进而没有达到spike应有的效果
    2023-01-02归属地:上海
    1
  • Jason
    第一次直观的感受spike方法
    2022-06-28
    1
  • 枫中的刀剑
    最大收获是Spike的方式也可以采取类似TDD的方式,甚至对于暂不关心的细节部分可以使用stub。
    2022-06-13
    1
  • 大碗
    通过实现“现有的接口”去了解组件交互的细节
    2022-09-05归属地:广东
收起评论
显示
设置
留言
6
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部