2012-05-04 74 views
15

An interesting thread就在我剛纔輸入這個問題時出現了。我不認爲它回答我的問題。「富域模式」能否違反單一責任原則?

我一直在努力與.NET MVC3,在那裏它是可取的貧血模型。查看模型和編輯模型最適合作爲啞數據容器,您可以將其從控制器傳遞到視圖。任何類型的應用程序流程都應來自控制器,並且視圖處理UI問題。在MVC中,我們不希望模型中有任何行爲。

但是,我們不希望控制器中有任何業務邏輯。對於更大的應用程序,最好將域代碼與模型,視圖和控制器(以及關於這個問題的HTTP)分開並獨立。因此,有一個單獨的項目,在其他任何項目之前提供一個領域模型(包含實體和值對象,根據DDD組成聚合)。

我已經做了一些嘗試,從貧血模型轉向更豐富的域代碼,並且我正在考慮放棄。在我看來,像是包含數據和行爲的實體類違反了SRP。

以Web上的一個非常常見的情況爲例,撰寫電子郵件。鑑於某些事件,在給定EmailTemplate,EmailAddress和自定義值的情況下組成EmailMessage對象是域的責任。模板以包含屬性的實體的形式存在,並且自定義值作爲用戶的輸入提供。我們還要說,爲了爭辯,EmailMessage的FROM地址可以由外部服務(IConfigurationManager.DefaultFromMailAddress)提供。鑑於這些要求,這似乎是一個豐富的域模型可以給的emailTemplate組成EmailMessage的責任:

public class EmailTemplate 
{ 
    public EmailMessage ComposeMessageTo(EmailAddress to, 
     IDictionary<string, string> customValues, IConfigurationManager config) 
    { 
     var emailMessage = new EmailMessage(); // internal constructor 
              // extension method 
     emailMessage.Body = this.BodyFormat.ApplyCustomValues(customValues); 
     emailMessage.From = this.From ?? config.DefaultFromMailAddress; 
     // bla bla bla 
     return emailMessage; 
    } 
} 

這是我在富域模型的嘗試之一。儘管添加了此方法,但EmailTemplate的責任是包含實體數據屬性和撰寫郵件。它大約有15行,似乎分散了這個班級的注意力,因爲它是一個EmailTemplate的實際意義 - IMO只是將數據(主題格式,正文格式,附件和可選/回覆地址)。

我最終將此方法重構爲一個專門的類,唯一的責任就是在給定之前的參數的情況下編寫一個EmailMessage,並且我對它感到高興。事實上,我開始更喜歡貧血的領域,因爲它幫助我將責任分開,使課程和單元測試更短,更簡潔,更專注。看起來,讓實體和其他數據對象「缺乏行爲」可以很好地分離責任。或者我在這裏偏離?

+1

一個豐富的域模型只需要足夠豐富的域相關的上下文。 – 2012-05-05 19:15:48

回答

19

支持富域模型而不是貧血模型的論點取決於OOP的價值主張之一,即保持行爲和數據彼此相鄰。核心優勢在於封裝和凝聚力,有助於推理代碼。豐富的域模型也可以被視爲information expert模式的實例。然而,所有這些模式的價值在很大程度上都是主觀的。如果它更有助於保持數據和行爲的分離,那就這樣做吧,儘管你也可以考慮其他人將會看到代碼。我更願意儘可能地封裝。在這種情況下,更豐富的域模型的另一個好處是可以將某些屬性設爲私有。如果一個屬性只能被類中的一個方法使用,爲什麼要公開它?

富域模型是否違反SRP取決於您對責任的定義。根據SRP,責任是一個需要改變的理由,這本身就需要一個定義。這個定義通常取決於手頭的用例。您可以聲明模板類的責任是模板,並帶來所有的影響,其中之一是從模板中生成一條消息。對其中一個模板屬性的更改可能會影響方法,這表明這些方法可能是單一的責任。此外,ComposeMessageTo方法是模板中最有趣的部分。模板的客戶不關心該方法是如何實現的,或模板類的屬性如何。他們只想根據模板生成消息。這也支持在方法旁邊保留數據。

+0

優秀的答案,謝謝。 – danludwig

0

那麼,這取決於你想如何看待它。

另一種方法是:「單責任原則是否違反了豐富的領域模型?」

兩者都是指導原則。在軟件設計的任何地方都沒有「原則」。然而,有好的設計和糟糕的設計。這兩個概念都可以用不同的方式來實現一個好的設計。

相關問題