2011-12-18 59 views
2

我使用三層架構與C#和SQL服務器數據庫作爲數據源。根據DRY的原則,驗證應該只在一個地方完成,而在我的情況下,只能是前端數據訪問層或數據庫存儲過程。參數驗證,存儲過程和數據訪問層在c#

所以我想知道是否驗證數據訪問層中的存儲過程參數還是將它留給存儲過程本身?

回答

6

DRY是一個重要原則,但defence in depth也是如此。

說到驗證輸入,您必須確保它是安全 - 這應該在每個級別上完成(因此在DAL和存儲過程中都是如此)。

至於驗證業務邏輯的數據,這應該在您的業務邏輯層(BLL)中。

+0

所以你建議選擇深入乾燥?因爲這兩個有嚴重的分歧。 – jim 2011-12-19 07:48:02

+0

@jim - 這是一個判斷問題。你必須決定什麼對你更重要。 – Oded 2011-12-19 11:53:06

1

如果您使用三層體系結構,我建議您使用ORM進行調查,而不是像Nhibernate或Linq到Entites。 ORM將爲您提供更好的重構能力和可維護性(對我而言,可維護性是最重要的事情,因爲根據我的經驗,它可以在更長的時間內提高質量)。

將驗證放入用戶界面並不明智,因爲在DAL(數據訪問層)中保護您的安全比在您的用戶界面中更安全,因爲它可以更容易地繞過(意外或故意)。考慮SQL注入。您應該驗證您的數據訪問權限,而不是僅限於您的用戶界面,因爲它很容易錯過您的用戶界面,並且容易繞過,因爲惡意用戶試圖訪問其他不允許訪問的數據。

我認爲在UI上進行可用性驗證或在數據訪問層進行安全性驗證是有意義的。我確實喜歡DRY校長在一個地方進行驗證,你仍然可以這樣做。如果您制定了一套通用的數據訪問層和用戶界面規則,那麼您將擁有一個安全可用的系統(通過即時反饋數據輸入)。另一種方法可能是針對不同層次採用不同的規則。例如,字段長度規則和數據輸入模式可以是UI特定的。例如,DAL可以強制執行數據。這是在多個地方進行驗證,但只要他們不是獨立地做同樣的事情,我想你會沒事的。在設計應用程序時,這是考慮最困難的領域之一,因爲驗證是一個橫切關注點,您如何實現這一點取決於您如何構建應用程序設計的其餘部分。

+0

我使用ORM與存儲過程。這就是我詢問參數的原因。你在UI或BLL中驗證它們一次。所以爲什麼再次在sp? – jim 2011-12-19 08:44:23

+0

縱深防禦。你應該假設任何圖層都能被繞過。我認爲這與防守應該如何像洋蔥,分層和多層次是類比的。 – Dessus 2011-12-19 20:48:58