經理類

Question

在最近的一個項目中，我已經接近完成了，我們使用了一種架構，它作爲Web /服務層交互的頂層使用XXXManager類。

例如，有一個按計劃運行的Windows服務，它將來自多個不同數據源的數據導入到我們的系統中。在這個服務中，幾個「經理」類被稱爲CPImportScheduleManager，CPImportProcessManager等。

現在，這些管理器類所做的不僅僅是傳遞方法在Web /服務層中使用。例如，我的UserManager.Register（）方法不僅僅是通過較低級別的組件持久化用戶，而且它還向用戶發送WAP推送並確定所使用的移動手機等。

有人向我建議，架構類型我是嘗試將OOP納入程序模型的常用手段。我可以在這裏看到他們的觀點，但是我想知道的是，對於這個頂級的類集，任何Web /服務層都可以簡單地調用相同的通用方法，而無需重寫代碼。因此，如果我想寫一個Web服務，在某些時候註冊了一個用戶，我可以再次調用UserManager.Register（）方法，而不必再次重寫所有的邏輯。

我從來不是最好的人解釋自己，但如果我的ramblings是有意義的，請隨時建議您的替代品。

乾杯，克里斯。

Answer 1

管理員是一種常用的命名策略，用於處理一組給定實體的工作流或複雜任務的服務。但是，如果它完成了工作，那麼它不一定是壞事。

我會遇到的重要問題是管理層下面發生了什麼？如果他們只是協調一個過程的工作流程，比如註冊一個用戶，那麼他們就是名字不同的控制器（MVC）。但是，如果它們包含了很多業務邏輯（我的意思是條件邏輯取決於一個實體或一組實體的狀態），那麼我會仔細看看是否可以通過使其成爲明確的邏輯自己的班級或以適當的責任將其移至班級。

更新： 從它的聲音，你有一個正確的想法。你有一組處理協調你的業務流程的類，它們不關心它們是否被WebService，Webform或其他使用。然後你說你想在你的Web服務層上添加這個層，並利用這些類。這是一件好事（tm）。

Answer 2

聽起來像你的設計動機很好 - 重用代碼。在某些方面，它與Martin Fowler's Service Layer的動機相似。但是，您可能會將太多的責任投入到這些經理類中。也許分開的基礎設施問題（WAP推送，用戶持久性）來自域問題（用戶註冊）。這Separation of Concerns會進一步增加可重複性，並且還會提高可維護性。