.NET遠程處理WCF - 構建解決方案以避免循環依賴

Question

我想轉換使用.NET Remoting的現有項目使用WCF。該項目的結構如下：

• UI
• BusinessLayer

的BusinessLayer項目是一個類庫，它包含了客戶端激活的對象DistributedProcessor它有方法IResult Process(IJobProcessor)。接口和具體類都在BusinessLayer庫中。具體的類IJobProcessor反過來在BusinessLayer中使用許多類。

對於.NET Remoting來說，這種情況非常理想。分佈式部分只是一個包含BusinessLayer並偵聽特定端口的Windows服務。客戶端使用Activator.GetObject()創建遠程對象。

將其轉換爲WCF，我意識到我有一個循環依賴問題，如果我項目結構如下：

• UI
• BusinessLayer - 引用WcfService
• WcfService - 引用BusinessLayer

該服務需要對BusinessLayer的引用，以便我可以通過網絡傳輸對象。 BusinessLayer需要引用WcfService，以便它可以調用WcfService上的IResult Process(IJobProcessor)方法。

能否接口IResult和IJobProcessor移動到一個單獨的項目BusinessLayerDistributed，如：

• UI
• BusinessLayer - 引用BusinessLayerDistributed
• BusinessLayerDistributed
• WcfService - 引用BusinessLayer，BusinessLayerDistributed

我的問題是：如果所有這些接口的具體類仍然在BusinessLayer中，那麼在將對象轉移到服務時，它們是否會作爲其具體的類來充分水合？用WCF做這件事有什麼竅門嗎？

Answer 1

爲什麼業務層必須調用服務層中的任何東西？業務層不應該具有關於服務外觀層的任何知識，也從客戶端調用正常服務 - 從不從業務層調用，因爲在服務架構中這是沒有意義的。

唯一的例外可以是雙向（雙向）通信，但即使使用這種體系結構，您仍然不會在程序集中使用循環依賴。有一些模式可以避免這種情況 - 例如業務層可以有事件，服務層可以訂閱它們。訂閱將在參考業務層的服務服務層完成。如果你不喜歡事件，你可以使用Observer GoF模式。

從業務邏輯調用服務層的另一有效的方案是完全面向服務的架構，但在這種情況下，每個「服務」將擁有自己的服務組件和業務邏輯組件，你會做其中的交叉調用。