是否將其視為驗證邏輯的重復？

Question

我有這樣的示例課

public class Customer
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int ContactNumber { get; set; }
    public System.DateTime DateOfBirth { get; set; }
}

在將客戶添加到數據庫之前，所有這些字段都是必填字段。 因此，在服務/業務邏輯層中，我對這四個屬性進行了驗證。 我確認FirstName和LastName不為空，並且ContactNumber大於0且DateOfBirth大於1930（僅作為示例）。 在將客戶對象傳遞到服務/業務邏輯層以進行驗證並將其添加到數據庫之前，在aspx頁面中，我進行了ContactNumber和DateOfBirth的類型檢查。 我使用簡單的函數，例如IsNumeric和IsDate。

我知道驗證應該在服務層中完成，這樣如果將來另一個應用程序需要使用此邏輯，就可以避免重復。

在aspx頁面中進行類型檢查，然后將對象傳遞給進行其他所有驗證的服務層是否常見？ 我知道一種避免這種情況的方法是使用javascript。 為了爭辯（從來沒有真正發生過），客戶端會關閉其javascript。 我在考慮的另一個選擇是將客戶添加到數據庫的函數接受其所有參數作為對象。 這樣可以避免在aspx頁面中進行類型檢查，而只需在服務層中進行即可。 但是，如果有大約20個屬性作為方法參數發送該怎么辦？

Answer 1

您應該同時在客戶端和服務器上進行驗證。

如果用戶只是犯了一個錯誤而忘記了輸入詳細信息，那么JavaScript驗證將在客戶端執行，並減少往返服務器的次數。 這還將提供更好的用戶體驗。

服務器端驗證至關重要，也應執行。 如果用戶曾經禁用JavaScript或攻擊者向您的服務器發送了惡意表單值，則此驗證將開始進行。由於您使用的是WebForms ，因此可以在框架內使用驗證控件，例如： RegularExpressionValidator並具有驗證摘要。

如果您想自己進行驗證，則此邏輯最好放在您描述的ValidationService中，該方法可以接受Customer類作為參數，而不是問題中所述的20個屬性。

您可能還需要考慮使用其他庫來防止XSS等攻擊。

Answer 2

實際上，這完全取決於您的設計和需求。 您提到的分數都是有效分數。 是的，理想情況下，您需要在服務/業務層中進行驗證，以防調用多個表示層，還因為服務/業務層是負責業務邏輯的那一層。

但是，您也很對，通常出於以下幾個原因在表示層中進行一些驗證：與用戶交互並顯示驗證錯誤的驗證。 另外，某些驗證技術只能在表示層中完成，例如JavaScript，該JavaScript用於使驗證更具響應性，而無需每次都訪問服務器。 但是，JavaScript驗證僅用於增強用戶體驗，而從不輕易將其視為真正的驗證，因為它很容易繞過它。

因此，從設計的角度來看，您在服務/業務層和表示層的驗證被認為是一個好的設計，而不是重復的工作。

但是，實踐有時並不完全遵循理論。 例如，某些驗證執行兩次可能會很長且很昂貴。 在這種情況下，您唯一想進行這種驗證的地方就是服務/業務層。