前一段时间，我在前端启动了一个带有JavaScript和HTML的Web应用程序，后端启用了PHP。其中我将backbone.js包含在我的前端框架中 我了解到在客户端服务器通信中有4种不同类型的操作：创建，更新，删除和读取 阅读：您发送特定型号的唯一ID，然后您将获得记录 创建：您发送记录数据。有时，id也会在客户端上创建，有时则在后端创建 更新：您将带有更改值的模型数据发送到后端 删除：您发送模型的ID，它将被删除。
但是，在实践中，您会了解到有特殊情况，这些情况不适合基本模式。
例如：登录，身份验证。
在第一个Web应用程序中，我想将此案例压缩到基本操作中。所以我使用了以下方法：
在我的身份验证中，我需要一些数据，某些用户帐户的某些属性。所以这是我的模特。我提供了id并获得了用户模型。
但是这种情况下，这种方法并不干净。
您不仅提供密钥（用户名），还发送用户名和密码。此外，您不会将用户数据作为此请求的答案，而是获取状态（成功/失败）。
现在我开始另一个应用程序。这次我想让我以干净的方式完成。
你可以帮我这个尝试吗？
当我考虑这种干净的方法时，我有以下注意事项：
在这个登录案例中，我想发送2个模型，一个传输，一个请求：
第一个模型是身份验证模型。它没有“id”，因为只有一个类的实例。它具有“用户名”，“密码”和“身份验证状态”属性。在答案中，后端填写身份验证状态。
第二个模型是用户模型。我提供用户名（id）并从服务器返回用户数据。
为了获得我的登录案例的清晰结构，您如何看待这些初步想法？第一种方法更好吗？
你的方法是什么？
答案 0 :(得分：1)
首字母缩略词CRUD是作为描述基本数据库操作的手段而发明的。您会发现它通常不适用于应用程序级逻辑。
例如，要对用户进行身份验证，您需要创建一个服务器命令，该命令接受来自客户端的凭据，然后服务器使用数据库操作（可能是读取操作）来检查这些凭据，如果有效，则提供客户端使用某种可用于将来操作的登录令牌。用户登录本身就是一个更高级别的功能，纯粹的数据库操作，正如您自己已经发现的那样，它不适合CRUD模型。
因此，如果您尝试将应用程序级别的功能建模为纯CRUD操作，我认为您将面临重大困难。应用程序使用数据库操作来完成它们的工作，但是有许多应用程序具有许多不直接映射到数据库操作的操作。实际上，甚至可能存在一些甚至不涉及数据库的应用程序级功能以及使用数据库操作来生成结果的许多其他功能，但不能直接映射到数据库操作。
您应该将服务器持久数据的接口视为与应用程序级API不同的模型。有时会有直接关联（例如设计用于获取数据的应用程序级别函数），有时根本不会有很多关联（例如登录或某种计算函数）。