不久前，我启动了一个 Web 应用程序，前端使用 JavaScript 和 HTML，后端使用 PHP。其中，我将backbone.js 添加到了我的前端框架中。
我了解到在客户端服务器通信中有4种不同类型的操作:创建、更新、删除和读取。
阅读:您发送某个型号的唯一 ID，然后您将收到记录。
创建:您发送记录数据。有时 id 也在客户端创建，有时则在后端创建。
更新:您将具有更改值的模型数据发送到后端。
删除:您发送模型的 id，它将被删除。
但是，在实践中，您会发现存在一些不符合基本模式的特殊情况。
例如:登录、身份验证。
在第一个 Web 应用程序中，我想将这种情况压缩到基本操作中。所以我使用了以下方法:
在我的身份验证中，我需要一些数据，某个用户帐户的一些属性。这就是我的模型。我提供了 ID 并取回了用户模型。
但这种情况下，这种做法并不干净。
您不仅提供 key (用户名)，还发送用户名和密码。此外，您不会获得用户数据作为对此请求的答复，而是获得状态(成功/失败)。
现在我开始另一个应用程序。这次我想以一种干净的方式完成我的工作。
你能帮助我完成这次尝试吗？
当我考虑这种干净的方法时，我有以下考虑:
在这种登录情况下，我想通过一次传输发送 2 个模型，并通过一个请求:
第一个模型是身份验证模型。它没有“id”，因为该类只有一个实例。它具有属性“用户名”、“密码”和“认证状态”。后端在应答中填写认证状态。
第二个模型是用户模型。我提供用户名 (id) 并从服务器获取用户数据。
为了为我的登录案例获得一个干净的结构，您对这些最初的想法有何看法。第一种方法更好吗？
你的方法是什么？
最佳答案
发明首字母缩略词 CRUD 是为了描述基本数据库操作。您会发现它通常并不真正适用于应用程序级逻辑。
例如，要对用户进行身份验证，您需要创建一个服务器命令来接受来自客户端的凭据，然后服务器使用数据库操作(可能是读取操作)来检查这些凭据，如果有效，则提供给客户端带有某种可用于将来操作的登录 token 。用户登录本身是一个比纯数据库操作更高级别的功能，并且您可能已经发现，它不适合 CRUD 模型。
因此，如果您尝试将应用程序级函数建模为纯 CRUD 操作，我认为您将会遇到很大的困难。应用程序使用数据库操作来完成其工作，但许多应用程序的许多操作并不直接映射到数据库操作。事实上，甚至可能有一些应用程序级函数根本不涉及数据库，还有许多其他函数使用数据库操作来生成结果，但不直接映射到数据库操作。
您应该将服务器持久数据的接口(interface)视为与应用程序级 API 不同的模型。有时会存在直接相关性(例如设计用于获取数据的应用程序级功能)，有时根本不会有太多相关性(例如登录或某种计算功能)。
关于javascript - 如何处理模型增删改查异常，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/30147655/