DDD中的應用程序級別設置？

只是想獲得有關如何處理實體配置細節的羣體想法。DDD中的應用程序級別設置？

我在想特別是高層設置，可能是admin-changed。最終可能存儲在應用程序或web.config中的那種東西，但是從DDD角度來看，應該明確地在對象中的某處設置。

爲了說明問題，我們舉一個基於web的CMS或博客應用程序爲例。

一個給定的博客條目實體有任何數量的情況下設置，如作者，內容等

但你也可能需要設置（例如）默認說明或站點中的所有條目應該開始關鍵詞如果他們沒有被作者改變。當然，你可以在課堂上做這些常量，但是網站所有者不能改變默認值。

所以我的想法如下：

1）使用類級（靜態）屬性來表示這些設置，然後將它們當應用程序啓動時，無論是從數據庫或Web設置它們的.config。

或

2）使用一個單獨的實體持有的設置，可能是一本字典，無論是直接使用還是有它是入門級

什麼打你所有的最容易的一員/靈活？我關心的第一個問題是，它不會讓我覺得可插拔（如果我最終希望添加更多功能），因爲更改實體的類方法也會使我改變應用程序本身（這感覺就像是OCP違規）。然而，第二個人覺得它更重，特別是如果我必須從字典中輸出或解析數值的話。

來源

2009-11-23 Paul

我想說的是，一個值是否可配置與域模型的角度無關 - 重要的是它是外部定義的。

假設您有一個必須具有名稱的類。如果名稱始終是必需的，則必須將其封裝爲不變量，而不考慮值的來源。以下是一個C＃示例：

public class MyClass 
{ 
    private string name; 

    public MyClass(string name) 
    { 
     if(name == null) 
     { 
      throw new ArgumentNullException("name"); 
     } 

     this.name = name; 
    } 

    public string Name 
    { 
     get { return this.name; } 
     set 
     { 
      if(value == null) 
      { 
       throw new ArgumentNullException("name"); 
      } 
      this.name = value; 
     } 
    } 
}

像這樣的類有效地保護了不變量：名稱不能爲空。領域模型必須封裝像這樣的不變量，而不考慮哪個消費者將使用它們 - 否則，他們不會達到柔性設計的目標。

但你問了關於默認值。如果您對Name有一個很好的默認值，那麼您如何將該默認值傳遞給MyClass。

這是工廠派上用場的地方。您只需將您的對象的構建與其實現分開。無論如何，這通常是一個好主意。無論您選擇抽象工廠還是生成器實現都不那麼重要，但Abstract Factory是一個很好的默認選擇。

MyClass中的情況下，我們可以定義IMyClassFactory接口：

public interface IMyClassFactory 
{ 
    MyClass Create(); 
}

現在，您可以定義從一個配置文件拉動名稱的實現：

public ConfigurationBasedMyClassFactory : IMyClassFactory 
{ 
    public MyClass Create() 
    { 
     var name = ConfigurationManager.AppSettings["MyName"]; 
     return new MyClass(name); 
    } 
}

確保代碼需要MyClass的實例使用IMyClassFactory來創建它，而不是手動新建它。

來源

2009-11-24 08:47:40

默認值是一個例子，也許是一個很差的例子;我熟悉工廠模式。另一個例子是應該應用於所有類的實例，但可以在應用程序級別更改。也許像加載到列表中的實例的數量（總是）或關於是否顯示註釋的規則。這些不是真的讓我成爲實例級的價值，還是我誤解了某些東西？ – Paul 2009-11-24 16:43:33

您總是可以將一個或多個相關值封裝到一個類型中，然後將該類型的一個實例注入到所有使用者中。出於效率原因（或任何其他原因），您可以選擇注入單個共享實例，而消費者不知道注入對象的生命週期。這會讓你的選擇保持開放。 – 2009-11-24 20:15:40

DDD中的應用程序級別設置？

回答

相關問題