這是一個ASP.NET MVC網站。可以從另一個應用程序服務中調用一個應用程序服務嗎?
以下領域驅動設計,我們有一個服務層。我們的控制器要求應用程序服務類執行各種任務,然後將結果發送到視圖。
業務邏輯由服務類執行。
因此,例如,我可能有一個AccountTasks
類,它負責註冊用戶,編輯他們的偏好等。現在,我需要能夠在註冊後立即自動訂閱用戶,或者更新他們的用戶偏好(然後我會更改新聞訂閱)。
新聞訂閱功能因此與帳戶註冊/修改密切相關。
但是,我覺得最好有一個單獨的NewsletterTasks
服務類來處理訂閱/更新/取消訂閱操作。
但是這個類不會被控制器使用,而是AccountTasks
類。
因此,工作流會是這樣:
-> request made to controller action
-> controller calls AccountTasks
-> AccountTasks creates a user acoount
-> AccountTasks calls NewsletterTasks
-> NewsletterTasks subscribes the user to the newsletter
-> AccountTasks returns the result to the controller
-> controller fetches the appropriate view and sends it to the client
或者,我會控制調用AccountTasks
第一,然後使用結果調用NewsletterTasks
。但是通過這種方法,我覺得控制器對工作流程知之甚多,而應該只是傳遞數據和結果。
任務是應用程序服務類,該項目基於S#arp架構,其中一些修改來自Who Can Help Me - 其中包括某些事情的命名約定。
可以從AccountTasks
撥打NewsletterTasks
嗎?你會如何做到這一點?
但是,如果我沒有引入域服務,那麼如果AccountTasks調用NewsletterTasks(並且具有依賴關係,我們使用DI),您認爲它還可以嗎?下面的Szymon說他只是把它放在控制器中,但是如果可以的話,我會盡量讓我的控制器啞巴,並將任何業務邏輯委派給服務類。雖然我不願意再添加一層,但這整個架構對我來說已經是一個巨大的飛躍。 :) – 2010-11-09 10:21:19
我傾向於同意 - 保持控制者'愚蠢'更加符合DDD。我將介紹** UserRegistrationService **的原因是使域操作*顯式*。但是,如果你的團隊說,打電話給AccountTasks-> NewsLetterTasks感覺更自然,那麼就去做吧。 DDD是讓事情變得更容易理解,而且更容易改變。 – 2010-11-09 10:40:45