如何返回能夠在服務器上執行的對象？

服務器向客戶端提供一個對象。這個對象應該能夠在服務器上執行。

服務器：

private string _S = "A"; 

public interface IFoo { void Bar(); } 

private class Foo : IFoo { 
    void Bar() { _S = "B";} 
} 

public IFoo GetFoo() { return new Foo(); }

客戶：

IFoo foo = serverChannel.GetFoo(); 
foo.Bar();

Remoting是傳統的（大家一直指着WCF代替）和WCF不支持此在所有基本（WCF: Is there a way to return an object that is able to execute on the server?），所以我應該如何實現這種行爲？如果需要，可以使用第三方組件。

我搜索了SO，但沒有發現類似的問題。如果之前確實已經回答，請告訴我，我會刪除。

來源

2010-03-13 mafu

我建議不要嘗試「遠程」對象。這是一個危險的想法。

對遠程狀態沒有本地控制。你永遠不會做。
試圖推論什麼是「真實」的狀態，什麼不是很快變得非常複雜。
從消息的角度來看，可能會導致設計從網絡的角度來看更「正確」 - 也就是說，正確分配責任並且不做不適當假設的設計。
基於消息的網絡應用程序幾乎肯定會更加健壯。
基於遠程應用程序內通常允許更快初步發展，但會導致從長遠看處理邊界條件一噸的額外時間等

真的，不這樣做。遠程對象有點不好。在覈心層面，網絡是關於傳輸數據。讓您的程序使用相同的模型將使您的生活變得更加容易，從長遠來看更容易。

來源

2010-03-14 00:50:06 kyoryu

的確如此。至於技術 - 意思是「.NET Remoting」 - 然而，人們成功地開發了應用程序。爲了避免大部分混亂，有一些規則：沒有回調，只使用singlecall，沒有狀態共享，只在普通程序集中放置接口/消息聲明，在客戶代碼中遠程調用應該是顯而易見的......所以，最後我們只剩下爲我們的遠程應用程序定義簡單的數據消息類。它看起來很像一個WCF應用程序。 :-) –

沒錯。消息傳遞的作品，以及任何成功的網絡應用程序，除了微不足道的示例之外，將會看起來很像是在進行消息傳遞。 – kyoryu

+1有趣的觀點。我不知道Remoting似乎經常導致這類問題。 – mafu

WCF確實是基於消息的，Remoting仍然有效....真正的問題是：爲什麼你不想工作基於消息？

來源

2010-03-13 23:57:17

因爲它會簡化我的應用程序設計:) – mafu

@mafuctrct：在設計方面，調用接口上的方法和發送消息沒有太大的區別。這是同一件事。藉助WCF，您可以獲得類似遠程處理的行爲，並具有與在代理實現後臺發送消息的接口。 –

是的，但我想有很多接口，以簡單的方式相互交互。據我所知，WCF並不是那麼容易，即使它可以被模仿。 – mafu

如果你想在WCF中進行類型共享 - 就像你所描述的那樣，並且在遠程處理中，在服務器和客戶端的常見程序集中共享（接口）聲明 - 你可以使用NetDataContractSerializer來完成。它helped others as well。

它的使用是令人沮喪的 - 就像遠程處理 - 基於合同的消息傳遞似乎是現在所有的憤怒。

我要補充一個適當的設計，您仍然有甚至NET遠程合同/基於消息的應用程序結束。您的共享接口將成爲操作合同，而您的共享數據類定義將描述您傳遞的數據合同/消息。

來源

2010-03-14 00:45:00

如何返回能夠在服務器上執行的對象？

回答

相關問題