應用程序設計 - 驗證和效率

我有一個ASP.Net應用程序，它有很多關於是否可以將對象提交到數據庫的業務規則。應用程序設計 - 驗證和效率

在基本層面上，一個人是衝刺的一部分，它是項目的一部分。

的基本規則是：

的人被分配到一個衝刺，但也許不是百米衝刺的整個持續時間（其中有一個開始和結束日期）。因此，當他們分配人員時，他的開始日期和結束日期必須介於衝刺的開始日期和結束日期之間（包括）。

一個項目可以有許多衝刺，但沒有一個可以在項目開始/結束日期之外。

我的解決方案有一個UI項目，服務層，業務層和數據訪問層。

我正在驗證中，但我不確定在應用程序的什麼級別，應該發生calidation。我不相信這是在用戶界面，因爲那時我需要在我的ASP.Net項目上重複驗證規則...也許我的WinForms前端...

我認爲它應該在業務邏輯中，因爲它有商業規則。所以，我打算創建一個名爲「Validations」的類，並且對於存儲到數據庫的每個業務對象，我在我的Validations中有一個名爲「IsObjectOK」的方法，接受要驗證的對象類型，並返回錯誤列表。

所以：

public List<String> IsObjectOK(SprintDto source) 
{ 
    // Do validations, and return list of errors, or NULL if none 
}

隨後的驗證規則的例子可能是：

var Project = BusinessLayer.GetProject(source.ProjectId); 
// check if Start/End dates fall between Project.Start and Project.End dates

如果有問題，將其添加到錯誤列表。

這似乎是一個好方法。我在尋找處理驗證方法的確認信息，以及任何提示和技巧？我不應該擔心數據庫命中嗎？我的意思是，對於衝刺來說，可能會有大約6或7個「規則」需要驗證，所有這些規則都可能從不同的表格中獲取數據。所以，這是7個數據庫查詢（加上連接開銷），一次保存。（SQL Server 2012）。我認爲這不是一個擔心，因爲它全部都歸功於業務層和數據層。

來源

2013-08-19 Craig

該技術取決於你在做CI，單例還是命令模式（CQRS），你在使用ORM嗎？但是，它應該在業務層上，而對數據庫的調用肯定會在大批量應用上表現不佳。 – Fendy

我不會擔心數據庫命中，直到你必須。在之後，有很多方法可以優化，讓您的架構合適。一個好的緩存層將使大多數消失，如果不是，你總是可以編寫一個單獨的域對象，即「SprintValidation」對象來包含驗證它所需的所有數據。

不要從性能上妥協，直到你知道這是一個問題。

來源

2013-08-19 13:40:37

當物體有可能變得不一致時，我總是儘可能早地儘可能早地設法制止障礙物。

早期

理想地，在非相干狀態的對象甚至不應該到達UI上述層。日期間隔通常是您在創建或修改Sprint時可以在客戶端輕鬆檢查的內容。用戶會很欣賞即時反饋，例如錯誤或不可能（例如灰色按鈕），雙重保險總是很好。儘管如此，使用更復雜的驗證可能並不可行。

牢牢

在業務，嘗試這些規則建模爲不變被執行一次，而不是驗證可能需要進行多次。換句話說，請確保您的業務對象是always valid。

強制在創建不變（在構造函數或工廠），讓你的對象不變Value Objects只要你能。在你的例子中PersonAssignment是一個很好的候選人。值對象是一個簡單的結構，你從來不需要修改，你只需要用另一個替換它們，所以保持它們始終保持一致就是小菜一碟。
對於不能完全不可變的對象（如Sprint），仍然可以過濾掉某些字段的不需要的修改。例如，修改屬性StartDate和EndDate的setter以不接受Project範圍外的日期。
有時，狀態變化相關的業務規則更復雜，涉及很多條件句。我發現用單一方法定義業務操作總是更好，並且在其中包含所有不變檢查，而不是讓您的實體處於故障狀態並嘗試事後驗證。

總之是用於變形的機會縮小到幾個地方，不要猶豫，沒有進行嚴格的執法，這樣你就可以依靠的信心，而不是懷疑。

來源

2013-08-19 14:12:46 guillaume31

應用程序設計 - 驗證和效率

回答

相關問題