3 架构
本章描述了 Ratpack 应用程序的高级概览。
1.3 强类型
Ratpack 是强类型的。除了在 Java（一种强类型语言）中实现之外，它的 API 还拥抱类型。例如，Registry 的概念在 Ratpack 中被广泛使用。Registry 可以被认为是一个使用类型作为键的映射。
这对于在 Groovy 中实现应用程序的 Ratpack 用户来说可能最有趣。Ratpack 的 Groovy 适配器 使用最新的 Groovy 功能来完全支持静态类型，同时保持一种惯用的、简洁的 Groovy API。
2.3 非阻塞
Ratpack 的核心是一个基于事件（即非阻塞）的 HTTP IO 引擎，以及一个使结构化响应逻辑变得容易的 API。非阻塞特性要求 API 具有与“传统”阻塞 Java API 不同的风格，因为 API 必须是异步的。
Ratpack 旨在为 HTTP 应用程序显著简化这种编程风格。它提供支持结构化异步代码（参见 “异步和非阻塞” 章），并使用一种创新的方法将请求处理结构化到一个自构建的、异步遍历的函数图中（它不像听起来那么复杂）。
3.3 组成部分
在以下部分中，使用“引号”来表示关键的 Ratpack 术语和概念。
一个 Ratpack 应用程序始于一个“启动配置”，正如您所料，它提供了启动应用程序所需的配置。一个 Ratpack“服务器”可以仅从一个“启动配置”构建并启动。启动后，“服务器”开始监听请求。有关这方面的更多详细信息，请参见 “启动” 章。
提供给“启动配置”的一个关键配置是“处理程序工厂”，它创建一个“处理程序”。“处理程序”被要求响应每个请求。一个处理程序可以执行以下三件事之一：
- 响应请求
- 委派给“下一个”处理程序
- “插入”处理程序并立即委派给它们
所有请求处理逻辑只是处理程序的组合（有关这方面的更多详细信息，请参见 Handlers 章）。重要的是，处理不受线程的约束，可以异步完成。“处理程序”API 支持这种异步组合。
处理程序在“上下文”上操作。“上下文”表示处理程序图中该特定点的请求处理状态。它的一个关键功能是充当一个“注册表”，它可以用来按类型检索对象。这允许处理程序通过公共类型从“上下文”中检索策略对象（通常只是实现关键接口的对象）。当处理程序将其他处理程序插入到处理程序图中时，它们可以对上下文注册表做出贡献。这允许处理程序向下游处理程序贡献代码（作为策略对象）。有关更多详细信息，请参见 “上下文” 章，以及下一节有关如何在实践中使用此上下文注册表的内容。
这是一篇关于 Ratpack 应用程序的高级抽象描述。可能还不清楚所有这些内容是如何转化为实际代码的。本手册的其余部分以及附带的 API 参考将提供详细说明。
4.3 插件和通过注册表扩展
Ratpack 没有插件的概念。但是，与 Google Guice 的集成 通过 Guice 模块促成了一种插件系统。Guice 是一个依赖注入容器。Guice 模块定义了要作为依赖注入容器一部分的对象。Guice 模块可以通过提供关键 Ratpack 接口的实现来充当插件，这些接口由处理程序使用。使用 Guice 集成时，所有 Guice 知道的对象（通常通过 Guice 模块）都可以通过“上下文注册表”获得。也就是说，处理程序可以通过类型检索它们。
为了了解这为什么有用，我们将使用将对象渲染为 JSON 到响应的要求。“上下文”对象提供给“处理程序”有一个 render(Object) 方法。此方法的实现只是在上下文注册表中搜索 Renderer 的实现，该实现可以渲染给定类型的对象。由于 Guice 可用的对象可通过注册表获得，因此它们可用于渲染。因此，添加一个带有给定类型的 Renderer 实现的 Guice 模块将允许它集成到请求处理中。这在概念上与普通的依赖注入没有区别。
虽然我们在上面的示例中使用了 Guice 集成，但这种方法并不局限于 Guice（Guice 不是 Ratpack 核心 API 的一部分）。另一个依赖注入容器（如 Spring）可以轻松使用，或者根本不使用。任何对象源都可以适应 Ratpack 的 Registry 接口（也有一个 构建器）。
5.3 服务和业务逻辑
Ratpack 对如何构建与请求处理无关的代码（即业务逻辑）没有意见。我们将使用术语“服务”作为对执行某种业务逻辑的对象的统称。
处理程序当然可以自由使用它们需要的任何服务。从处理程序访问服务的两种主要模式是：
- 在构造处理程序时将服务提供给它
- 从上下文注册表中检索服务