處理許多參數和業務規則的設計模式

Question

我正在創建一個負責創建「作業」的項目，該作業由一個或多個通過DAL持久保存到數據庫的「任務」組成。作業和任務列由根據業務規則設置的值組成。

這個類現在變得越來越複雜和笨拙，因爲業務規則規定它需要訪問整個系統中的許多數據庫來決定是否可以創建作業和/或應該如何創建作業。

爲了進一步複雜化，需要提交一份作業列表，並且需要以各種方式（作爲引用程序集，通過Windows服務或通過Web服務）進行調用。

下面是它做的事情的一些例子：

• 生成作業成本估計
• 採取的帳戶和/或用戶到該工作分配
• 發出事件的作業提交進步來自外部，用戶自定義列表跟蹤數據
• 合併（的.csv，.xls的，等。）
• 從本地驅動器可訪問網絡驅動器複製文件（如有必要）

我的問題是：什麼是最佳實踐或設計模式，使其儘可能易管理和簡單？

Answer 1

似乎這個類需要重構，因爲它似乎違反了Single Responsibility Principle。我建議上面的每一個重點都有其獨立的實現類。通過這種方式，您將實現facade pattern，您的主類代表系統正在執行的高級抽象。

Answer 2

鑑於您對需求的描述，沒有真正的「簡單」方法可以解決這個問題。其必備的功能是龐大而多樣的。我唯一的建議是將整個事情變成一個DLL庫（甚至是一組DLL），以分離各個前端，以便引用程序集不需要依賴Windows服務（例如）;並堅持像鬆耦合這樣的基本OOP指令。

Answer 3

如果不從頭開始保持清潔，這種類型的程序會變得非常混亂。我自己總是試圖堅持基本的三層應用程序（演示，業務，數據）。以這種方式建立應用程序有很多好的信息，最好做some demo projects，並閱讀其他人對此主題的評論。這裏是MSDN reference。

我自己不得不重新設計一個非常相似的應用程序。一旦我將我的數據層分離出來並從其他所有方面中解放出來，我的生活變得更加容易了。

我最好的建議是花時間到計劃很多。使用圖表，流程圖等等。當一個程序非常複雜時，我喜歡在我開始編寫代碼之前爲我的圖層奠定基礎。

Answer 4

除了推薦使用SOLID並且花費更多的時間來保持乾燥之外，我會建議在系統中引入規則的概念。

通過對規則進行建模，您可以切換到更具可配置性/靈活性的方法。您可以組合多個規則來公開影響作業結果和相關任務的不同操作。

這使您可以制定由其他人組成的規則。根據您的情況，這可能會大大簡化您處理它的方式，因爲涉及隱含在所有這些系統中的規則的操作可以表示爲簡單規則的組合。我會盡可能保持簡單，但隨着您的擴展，您可能會發現需要採用不同的方式來組合規則，並且模式會自行出現。

至於SOLID，我建議檢查the ebook here，並嘗試保持演變的代碼方法。