2010-09-05 127 views
1

好的,我已經看到關於此的其他帖子,但沒有真正明確回答我的問題。在哪裏保持驗證邏輯

在應用程序中應該驗證邏輯的位置?

我有一個小應用程序,允許將新產品插入到應用程序數據庫中。有不同領域的不同產品,即產品名稱,訂單號,說明等。新產品可以插入,現有產品可以更新。因此,在插入新產品時,必須驗證所有字段,但是當現有產品正在更新時,只有正在更新的字段需要驗證,即可能只是正在更新描述,以便只驗證該字段。

我想到一個抽象類和兩個具體類的全部和部分產品驗證器,每個驗證器都有自己的驗證邏輯包含在類級別。

我有這樣的感覺,但必須有更好的模式 - 任何建議?

+0

請注意,驗證不限於單場驗證。驗證有很多級別,第一次在字段驗證之後是記錄/對象驗證規則,其中字段被認爲是相互關聯的。那麼你很可能會遇到這樣的情況:當你改變FieldA時,即使它沒有被改變,FieldB也是無效的。一個(做作的)例子就是將某人的年齡改爲低於法定駕駛限制。如果你還有一個領域給出他們的駕駛證號碼,如果該字段有實際價值,現在將是完全不合邏輯的 – 2010-09-06 06:29:31

回答

1

在應用程序中應該驗證邏輯是什麼?

取決於你的架構。可以在多個階段處理驗證以實現響應。通常情況下,儘管模型/控制器在給定的MVC體系結構中似乎是一個很好的地方。這個問題回到了Joel's old forum in context of the MVC architecture。模型應該負責接受/拒絕輸入似乎是合理的。

因此,當一個新產品被 插入,那麼所有字段都必須 驗證

是。

但是當現有產品 正在更新則只有場 更新需要驗證 即也許只是descirption被 被這樣只有場 應驗證更新。

你不可能預知哪一個確切的部分將被更新。所以,您需要爲所有字段(數據庫的列)編寫驗證器。

您可以簡化生活並擁有一個驗證器類(除非驗證一組特定的屬性過於複雜/耗時)。

+0

我會知道它的一部分或整個產品作爲我的驗證器是否會通過一組字段進行驗證。如果產品ID存在於系統中,那麼我們相當正確地認爲,我們正在處理更新,而不是插入。因此,根據產品是否存在,我有兩條路徑。這是我的第一次檢查。因此,我是否應該創建一個驗證該字段的每個字段的方法,然後每個驗證器類(部分和整體)都可以擁有自己的邏輯來調用其所需的方法? – Bob 2010-09-05 21:48:08

+0

@Bob:從_insert_區分_update_很容易。有時候我曾經研究過基於SOA的WebService,並且有這個確切的問題需要解決。我所做的就是爲每個領域添加驗證器(而不是爲每個領域分派一個類,因爲這些領域主要是標量/平凡類型)。查詢創建邏輯(將字段連接到SQL語句)自動調用驗證。另外請注意,我會推薦使用現有的驗證器,而不是自己的。但是,如果你想自己學習白名單/黑名單。 – dirkgently 2010-09-05 21:55:50

+0

驗證更新時,如何處理大量的條件語句,以確認哪些字段正在更新以及哪些字段未更新?或者你只是接受這將會發生更新? – Bob 2010-09-05 21:58:34

1

假設您正在爲您的項目使用MVC模式,驗證邏輯將屬於模型。如果您正在開發一個n層項目,請將驗證邏輯放在您的業務層中,並確保沒有先前驗證的情況下才能編寫任何實體。

但我總是會驗證整個對象。對已經改變的內容進行分類並僅對其進行驗證似乎是過度殺傷性的。除非你確切地知道(通過測量)這將是一個性能問題。

0

有幾個地方,你可以和應該做的驗證,因爲有不同程度的有效性:

  1. 在客戶端,這需要能夠在切換出UI控制的檢查領域;應該檢查需要匹配日期的正則表達式(如「yyyy-MM-dd」)的字符串。在Web UI上,這通常使用JavaScript完成。
  2. 在服務器端,當輸入參數綁定時應檢查對象的有效性。
  3. 有效的對象在處理時仍然需要檢查「業務有效性」(例如,「用信用卡支付時需要有效的信用卡號碼」)。

您應該執行客戶端和服務器端驗證。當輸入綁定到對象時,綁定和驗證由服務層完成。他們還在處理用例時檢查業務規則。