什么是REPR设计模式？

REPR是Request-Endpoint-Response的缩写。

Endpoint端点是这里的重要关键词。它应该与MVC控制器相反。控制器很快就会变得臃肿。MVC 控制器本质上是一种反模式。他们是恐龙。它们是从不互相调用并且很少在同一状态下操作的方法的集合。MVC 控制器没有凝聚力。它们往往会变得臃肿并失去控制。它们的私有方法（如果有）通常仅由单个公共方法调用。

如果采用 API 端点呢？您的 API 是围绕单个端点类设计的。每个端点都有一个处理请求的方法，并可定义可选的请求或响应。

REPR设计模式将 Web API 端点定义为具有三个组件：请求、端点和响应。它简化了常用的MVC模式，更专注于API开发。

经典的 MVC 模式（模型、视图、控制器）已经存在了几十年，并且长期以来一直成功地用于 UI 应用程序。

REPR请求-端点-响应是一种比 MVC 更简单的 API 端点开发模式。没有视图。没有臃肿的控制器。您唯一关心的模型是请求和响应。

使用REPR方法，您的 API 是围绕各个端点类设计的。每个都有一个单独的 Handle 方法，其作用就像一个单独的控制器操作（因为它是在幕后）。每个端点可以定义一个可选的请求类型和一个可选的响应类型。总之，您只需使用以下类型来定义端点：

• 请求Request
• 端点Endpoint
• 响应Response

MVC 中的大 M 模型（包含所有业务逻辑）怎么样？REPR模式并不规定您如何在端点内实现逻辑。您可以将所有逻辑放入 Handle 方法中。但对于重要的应用程序，您可能希望将一些服务注入端点，并最大限度地减少其中存在的非 UI 逻辑的数量。

REPR 模式不是 REST 模式。
这不是基于资源的模式。它是定义 API 端点的模式。它不是定义资源的模式。您可以使用它来定义 RESTful 资源，但也可以使用它来定义 RPC 样式的端点。由你决定。

如果您想将 REPR 与 REST 样式的资源一起使用，您只需在请求和响应类型中包含适当的资源架构即可。例如，如果您有一个Customer资源，则可能有一个GetCustomerRequest和一个GetCustomerResponse类型。请求类型可能包括客户端生成的CustomerId属性，而响应类型将包括新创建的Customer资源作为属性（或可能找到该资源的路由的链接）。