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,並且我對它感到高興。事實上,我開始更喜歡貧血的領域,因爲它幫助我將責任分開,使課程和單元測試更短,更簡潔,更專注。看起來,讓實體和其他數據對象「缺乏行爲」可以很好地分離責任。或者我在這裏偏離?
一個豐富的域模型只需要足夠豐富的域相關的上下文。 – 2012-05-05 19:15:48