为什么要有请求模型？答案

【问题标题】：Why have a Request Model?为什么要有请求模型？
【发布时间】：2019-04-21 06:17:03
【问题描述】：

创建请求模型对象并将其传递给交互器的基本原理是什么？

为什么不直接将数据作为参数传入并跳过分配？对我来说，这似乎是一个非常短暂的对象。

我错过了什么？

【问题讨论】：

【解决方案1】：

来自鲍勃叔叔的书“清洁建筑”：

用例类接受简单的请求数据结构作为其输入，并返回简单的响应数据结构作为其输出。这些数据结构不依赖于任何东西。它们并非源自 HttpRequest 和 HttpResponse 等标准框架接口。他们对网络一无所知，也不分享任何可能存在的用户界面的任何陷阱。

关键方面是“请求数据结构”（注意“s”）是独立且简单的数据结构。只要您传递给交互器的数据结构是您的编程语言/环境（例如 .Net 或 Java）的原语，或者您已在用例层中定义了这些数据结构，就不必为每个交互器创建专用的请求模型类型.

【讨论】：

【解决方案2】：

我使用请求模型来验证“第一个视图”中的输入值 - int 值是 int 值，字符串不超过 5 个字符等等。所以它承担主要责任：虚拟（类型）检查和对话。

还 requests 有助于将多个输入值分组到一个块中。对于响应，我只讨论具有可选“有效负载”（预期响应）和许多关于错误的标志的结构。我第一次尝试放置错误对象（当然来自用例层），但遇到了问题：需要将问题转换为实际的视图实现、语言。有了标志，我就有了关于具体问题的迹象，这可能发生在用例中，我知道我应该为它们实现处理。

【讨论】：

UPD：另外，不要试图将所有验证和解析输入数据放在请求模型中。我们被困住了，而不是，我们的业务层有 UseCaseRequest，它知道 Django！ =) 我们需要从 django-request 对象中读取文件，我们在请求模型中执行此操作 - 我认为这不好。现在我们将解析移到单独的函数中，返回这个 UseCaseRequest。并且这个函数声明在外层——我们知道所有关于 django、web 等的地方。