在域類中使用服務定位器模式有時可以嗎？

這個問題可能更適合程序員堆棧。如果是這樣，我會移動它。不過，我想我可能在這裏得到更多答案。在域類中使用服務定位器模式有時可以嗎？

到目前爲止，我的域中的所有接口依賴項都是使用執行程序集中的DI來解決的，目前它是.NET MVC3項目（+ Unity IoC容器）。不過，我已經運行了一個場景，我認爲服務定位器可能是更好的選擇。

域中存在一個存儲（緩存）來自URL的內容的實體。具體而言，它存儲來自元數據URL的SAML2 EntityDescriptor XML。我有一個單一的方法的接口IConsumeHttp：

public interface IConsumeHttp 
{ 
    string Get(string url); 
}

當前實現使用靜態WebRequest類在System.Net：

public class WebRequestHttpConsumer : IConsumeHttp 
{ 
    public string Get(string url) 
    { 
     string content = null; 
     var request = WebRequest.Create(url); 
     var response = request.GetResponse(); 
     var stream = response.GetResponseStream(); 
     if (stream != null) 
     { 
      var reader = new StreamReader(stream); 
      content = reader.ReadToEnd(); 
      reader.Close(); 
      stream.Close(); 
     } 
     response.Close(); 
     return content; 
    } 
}

哪個緩存XML內容的實體存在作爲非根在一個更大的實體集合中。對於剩餘的聚合，我實現了一個有點大的Facade模式，這是MVC控制器的公共端點。我可以注入IConsumeHttp依賴在門面構造像這樣：

public AnAggregateFacade(IDataContext dataContext, IConsumeHttp httpClient) 
{ 
    ...

我這個看到的問題是，只有一個門面方法有這個接口的依賴關係，因此它似乎傻注入它的整個門面。 WebRequestHttpConsumer類的對象創建不應該增加很多開銷，但是域並不知道這一點。

我正在考慮將實體的所有緩存邏輯移出到單獨的靜態工廠類中。不過，代碼將取決於IConsumeHttp。所以我正考慮在靜態工廠方法中使用靜態服務定位器來解析IConsumeHttp，但只有當需要初始化或刷新緩存的XML時。

我的問題：這是一個壞主意嗎？在我看來，確保XML元數據得到適當緩存應該是域的責任。域作爲其他相關操作的一部分定期執行此操作（例如獲取SAML Authn請求的響應，更新SAML實體ID或元數據URL等）。或者我只是擔心它太多？

來源

2012-03-21 danludwig

相關：http://stackoverflow.com/questions/4835046/why-not-use-an-ioc-container-to-resolve-dependencies-for-entities-business-objec – Steven 2012-03-21 15:11:20

IMO這是一個有效的問題所以。 – Steven 2012-03-21 15:11:43

@Steven感謝您的鏈接，信任投票以及您的博客，瞭解如何使用您的架構的查詢+命令端。非常有趣的東西。 – danludwig 2012-03-21 16:31:30

它似乎對我來說，它應該是該域的責任確保XML元數據進行適當緩存

我不知道這件事，除非你的域名實際上是關於元數據操作，http請求等。對於具有非技術領域的「正常」應用程序，我寧願在基礎結構/技術服務層處理緩存問題。

我這個看到的問題是，只有一個門面方法有這個接口的依賴，因此它似乎傻注入它的整個門面

顯然，外牆通常因爲他們自然傾向於指向許多依賴關係，所以不適合構造器注入。您可以考慮其他類型的注射，或者如您所指，使用定位器。但是我想要做的是問自己一個Facade是否真的合適，並考慮使用更細粒度的對象，而不是所有控制器中的同一個大接口。這將允許更多的模塊化和臨時注入，而不是預先大量增加大量物體。

但是，這可能只是因爲我不是一個大風扇門面;）

來源

2012-03-22 13:41:16 guillaume31

感謝您的輸入。該域不是關於HTTP，並且不引用System.Web，MVC或任何類似的dll，這就是爲什麼我將HttpConsumer包裝在界面中的原因。這是它在域中使用的唯一情況。控制器處理SAML http事件並使用操作系統的元數據，例如發送Authn請求。看起來好像讓控制器確保域名有正確的XML太細，給客戶太多的責任。該網域已經知道該網址，並且可以自行完成。你確實有一點，我正在研究其他模式。 – danludwig 2012-03-22 14:41:00

在您的評論對@ ian31，你提到「彷彿使控制器確保域具有正確的XML過於詳盡，給客戶太多的責任「。出於這個原因，我寧願控制器要求它的服務/存儲庫（它可以實現緩存層）爲當前XML的正確&。對我來說，這個責任是很多要問的域實體。然而，如果你對你所描述的責任沒有問題，並且你提到創建對象沒有太多開銷，我認爲將IConsumeHttp留在實體中是沒有問題的。
堅持這個責任，另一種方法可能是將這個接口下移到一個子實體中。如果這對您的情況是可能的，至少依賴關係僅限於需要它的場景。

來源

2012-03-27 03:42:30

感謝您的回答，並對已故的回覆感到抱歉。在這個項目中，沒有服務層。 MVC項目直接訪問域表面，使用工廠和門面模式。 IConsumeHttp依賴不在域實體上，它在另一個域類上。最終，元數據存儲在域實體屬性中，但它不是執行HTTP查找的實體。另外，當我說「緩存」時，我並不是指使用內存中的緩存。我的意思是XML內容存儲在實體中，並使用元數據URL定期刷新。 – danludwig 2012-04-02 20:17:03

在域類中使用服務定位器模式有時可以嗎？

回答

相關問題