爲通用服務建議架構模式

我們正在連接到描述某些Stock Tase信息的不同服務。現在有三種服務。每個服務以不同的方式返回信息：XML，Json，Pipe分隔的字符串。服務的數量在不久的將來會增長。爲通用服務建議架構模式

我想以最靈活的方式實現這一點，並提供最大的抽象。唯一的模式（我熟悉的模式）是工廠模式或抽象工廠。也許即使是戰略模式也是一種選擇。

也許你可以建議更好的實施方式？

摘要：

StockInformationParser 
-> Connects to Service 1 || Service 2 || or Service N 
-> Parses and analyses information 
-> returns StockInformationInfo.

來源

2013-04-24 StringBuilder

我會去工廠模式接受標準格式，然後適配器模式來標準化每個不同的服務。 – eomeroff 2013-04-24 08:05:59

我假設所有這些外部服務最終映射到一個相同的域模型。

在這種情況下，您可以：

創建可通過客戶端（S）被消耗，與這些客戶優化數據契約操作的內部服務。
內部服務使用底層存儲庫和域模型。
存儲庫負責抽象數據的檢索方式。他們從內部獲取來自外部提供者的數據，並將這些數據映射到您的域對象。您可以爲每個外部服務編寫一個提供程序，並將其用於存儲庫中。如果添加了外部服務，則只需添加一個新的提供程序並將其添加到存儲庫邏輯。

我個人喜歡IoC，所以我會爲每個組件創建接口並注入具體實例;這使得它更加靈活和可測試。

來源

2013-04-24 08:28:20

我喜歡Ioc和依賴注入一起工作，但不幸的是，我不能看到它與我的問題一起工作，可能是因爲體系結構不理解...... – StringBuilder 2013-04-24 08:34:35

例如，您有一個IExternalDataProvider，它定義了您需要與外部服務，如Get操作。然後爲每個外部服務編寫一個具體的實現，比如XmlExternalDataProvider通過調用外部服務來實現IExternalDataProvider，解析XML並返回域對象;等等。 – 2013-04-24 08:37:46

請你指點我一些你的方法的簡短例子。 – StringBuilder 2013-04-24 08:40:17

關於你的情況，我建議你應該申請更多的設計模式，它應該爲如下解決您的問題結合在一起： 1.外觀模式：它工作的聯絡點類在連接多個服務時降低複雜性。

對於每個結果返回每項服務，您可能需要用同樣的方法，但每種格式JSON，XML，RSS，......相同的方法，但不同格式的解析引擎，所以你應該申請策略模式來解決。
每個服務都需要一個方案工廠來連接，所以抽象工廠或工廠設計模式都是合適的。
最後一件事情，你會想要的結果是抽象易於更改或稍後擴展，你可以在這裏應用代理模式。

希望得到這個幫助。

來源

2013-04-24 08:09:36

感謝您的回覆，我會進一步調查。 – StringBuilder 2013-04-24 08:16:06

我會有一點不同的方法。如何創建數據庫並使用這些服務填充數據庫，然後可以使用最喜歡的SQL輕鬆查詢數據庫並使用Group By，Order和Joins。

優點是，

沒有必要重塑查詢轉接，畢竟你需要查詢。
無需擔心格式不同，一旦提取的數據保持爲數據庫中的第行。
改進的緩存如果發生服務故障或連接問題，您仍然可以看到過去的數據。

來源

2013-04-24 08:21:43

最後，結果保存到DataBase中...但我正在嘗試構建Analysis Analysis，我們從某些服務中獲取一些信息，然後應用我們自己的Analysis系統，並將結果存儲到數據庫 – StringBuilder 2013-04-24 08:27:43

我是在分析之後，但在應用任何分析之前，談論將信息直接存儲在服務中，只是原始錶轉儲。你的服務返回某種行嗎？ – 2013-04-24 08:41:16

爲通用服務建議架構模式

回答

相關問題