如何處理模型異常例外

Question

前一段時間，我開始使用前端的JavaScript和HTML和後端的PHP開發Web應用程序。其中我包括backbone.js到我的前端框架。
我瞭解到，在客戶端服務器通信中，有4種不同類型的操作：創建，更新，刪除和讀取。
閱讀：您發送特定模型的唯一標識，並將記錄返回。
創建：您發送記錄數據。有時候，這個id也是在客戶端創建的，有時候它是在後端創建的。
更新：您將帶有更改值的模型數據發送到後端。
刪除：您發送模型的ID，它將被刪除。

但是，在實踐中，你會發現，有些特殊情況不適合基本模式。

例如：登錄，認證。

在第一個Web應用程序中，我想將這個案例壓縮到基本操作中。所以我使用了以下幾種方法：

在我的身份驗證中，我需要一些數據，某些用戶帳戶的某些屬性。所以這是我的模式。我提供了id並獲得了用戶模型。
但是這種情況下，這種做法並不乾淨。

您不僅提供密鑰（用戶名），而且還發送用戶名和密碼。此外，您不會將用戶數據作爲對此請求的答案，而是獲取狀態（成功/失敗）。

現在我開始另一個應用程序。這一次我想讓我以乾淨的方式完成。

你能幫我做這個嘗試嗎？

當我想到這個乾淨的方法，我有以下幾點考慮：

在這種登錄的情況下我想送2個模型與一個傳輸，以一個請求：

的第一個模型是身份驗證模型。它沒有「id」，因爲這個類只有一個實例。它具有「用戶名」，「密碼」和「身份驗證狀態」屬性。在答案中，後端填入認證狀態。

第二個模型是用戶模型。我提供用戶名（id）並從服務器獲取用戶數據。

您如何看待這些首要想法，以便爲我的登錄案例獲得一個乾淨的結構。第一種方法更好嗎？

你的方法是什麼？

Answer 1

首字母縮略詞CRUD是作爲描述基本數據庫操作的手段而發明的。你會發現它通常不適用於應用程序級邏輯。

例如，要驗證用戶，您需要創建一個服務器命令來接受來自客戶端的憑據，然後服務器使用數據庫操作（可能是讀取操作）來檢查這些憑據，如果有效，客戶端提供某種可用於未來操作的登錄令牌。用戶登錄本身就是一個更高級別的功能，它是一種純粹的數據庫操作，正如您可能已經發現的那樣，它不適合CRUD模型。因此，如果您試圖將您的應用程序級別函數建模爲純粹的CRUD操作，我認爲您會遇到很大困難。應用程序使用數據庫操作來完成他們的工作，但是有很多應用程序有許多操作不直接映射到數據庫操作。實際上，甚至可能有一些應用程序級別的函數根本不涉及數據庫，還有許多應用程序級別的函數使用數據庫操作來生成結果，但不直接映射到數據庫操作。

您應該將服務器持久數據的接口作爲與應用程序級API不同的模型。有時候會有直接的相關性（比如用來獲取數據的應用程序級函數），有時根本就沒有太多關聯（比如登錄或者某種計算函數）。