如何处理模型原始异常

Question

不久前，我启动了一个Web应用程序，该Web应用程序的前端是JavaScript和HTML，后端是PHP。 除其他外，我在自己的前端框架中包括了ribs.js。
我了解到，在客户端服务器通信中，有4种不同类型的操作：创建，更新，删除和读取。
阅读：您发送特定模型的唯一ID，然后将记录取回。
创建：发送记录数据。 有时，id也会在客户端上创建，而其他时候会在后端上创建。
更新：您将具有更改后的值的模型数据发送到后端。
删除：您发送模型的ID，它将被删除。

但是，然后在实践中，您会发现有些特殊情况不适合基本模式。

例如：登录，身份验证。

在第一个Web应用程序中，我想将这种情况压缩到基本操作中。 因此，我使用了以下方法：

在身份验证中，我需要一些数据，某个用户帐户的某些属性。 这就是我的模型。 我提供了ID，并恢复了用户模型。
但是这种情况下，这种方法并不干净。

您不仅提供密钥（用户名），而且还发送用户名和密码。 此外，您不会获得用户数据作为此请求的答案，而是状态（成功/失败）。

现在，我启动另一个应用程序。 这次我想以一种干净的方式完成工作。

您能帮我这个尝试吗？

当我想到这种干净的方法时，我有以下注意事项：

在这种登录情况下，我想通过一次发送发送一个请求，发送两个模型：

第一个模型是认证模型。 它没有“ id”，因为该类只有一个实例。 它具有“用户名”，“密码”和“身份验证状态”属性。 在答案中，后端填写身份验证状态。

第二个模型是用户模型。 我提供用户名（id）并从服务器获取用户数据。

您如何看待这些最初的想法，以便为我的登录案例提供一个清晰的结构。 第一种方法更好吗？

你的方法是什么？

Answer 1

首字母缩写词CRUD被发明为描述基本数据库操作的一种手段。 您会发现它通常并不真正适用于应用程序级逻辑。

例如，要对用户进行身份验证，您需要创建一个服务器命令，该命令接受来自的凭据，并且一个客户端，然后服务器使用数据库操作（可能是读取操作）来检查这些凭据，并在有效时向客户端提供某种形式的凭据。可以在将来的操作中使用的登录令牌。 用户登录本身就是一个更高级别的功能，它是纯数据库操作，并且，如您可能已经发现的那样，它不适合CRUD模型。

因此，如果您尝试将应用程序级功能建模为纯CRUD操作，那么我认为您将遇到很大的困难。 应用程序使用数据库操作来完成其工作，但是许多应用程序的许多操作没有直接映射到数据库操作。 实际上，甚至可能有一些应用程序级别的功能甚至根本不涉及数据库，还有许多其他功能使用数据库操作来生成结果，但并不直接映射到数据库操作。

您应该将与服务器持久性数据的接口考虑为与应用程序级API不同的模型。 有时会有直接的相关性（例如设计用于获取数据的应用程序级函数），有时根本没有太多的相关性（例如登录名或某种计算功能）。