驗證設計和文檔

Question

在一個完美的世界裏，你必須投入在業務邏輯層的驗證（驗證），而不是在呈現或持久層。實際上你可以（或者想）把它放在任何地方。

允許作簡單的樣品（使用像JSF或ZK框架web的應用）：一定輸入字段接受0001和0500之間4位

1. 你可以使用的約束特徵你的web框架來做到這一點。方便用戶，不需要額外的服務器負載。

2. 你可以在業務層（例如java-ejb）做到這一點。萬無一失，因爲所有使用相同ejb的應用程序都將使用相同的驗證。最終不好，因爲你需要在評估後向用戶拋出錯誤。需要往返於服務器。

3. 如果有人輸入（通過持久層）非數字值或超過4位數的值，您可以依靠（部分）數據庫失敗。醜陋。

簡歷：您可以在1.和2.中做到這一點（多餘）。（讓用戶感覺很好，並使所有應用程序保持一致）。 （加上DB col的長度將是4）

現在問題：你如何記錄這個驗證？文本文檔或UML圖？在某種程度上，您可以在多達3個位置擁有業務邏輯。在複雜的系統中，這幾乎無法跟蹤和理解。

上述示例的現實生活場景：您需要將數字從4改爲5。如果沒有文檔，您需要尋找可能需要更改的位置。

你會遇到什麼？任何提示或工具呢？

歡呼
斯文

Answer 1

在我的項目之一，我能夠做的所有使用正則表達式我的驗證。幸運的是，我的數據庫（PostgreSQL）支持正則表達式約束。通過在數據庫模式級定義正則表達式，我可以輕鬆地在整個應用程序中使用正則表達式驗證。然後由應用程序邏輯繼承，然後由客戶端JavaScript驗證引擎繼承。

因爲，我的同事和我都是SQL流利的人，所以這是自我記錄給我們的。快速檢查數據庫的表格定義會告訴你驗證規則。如果我們需要生成正式的文檔，那麼將信息從數據庫元數據中提取出來將是微不足道的。

我知道我在這裏的經驗有點獨特，但我想強調正則表達式是一種相對自我記錄的便攜式解決方案。

Answer 2

訣竅是堅持DRY（不要重複自己）校長。

有實現這個目標的幾種不同的方式：

1. 在傳播到 業務和UI層
2. 定義業務層（Java）的約束DB（以利亞的 法）規定的約束和使用GWT運行相同的代碼使用GWT
3. 等等，我相信有很多其他方法可以實現相同的結果。

複製約束在不同的地方，然後「記錄」它（添加另一個重複！）是無效率的祕訣！