我們正在嘗試提出一種架構方法來設計應用程序，其中前端作爲基於瀏覽器的xaml應用程序運行。通過互聯網使用WCF/WPF的類型保真度
這個應用中的聯繫人正在使用WCF建立在網絡服務器上的服務，對於持久性使用的NHibernate的WCF服務主機的域模型（因此它是通過使用接口列表和設置和這樣的休眠意識到）
我理解當使用SOAP Web服務時，只有模式是共享的而不是類型，但是我們想共享類型，因爲類型會有方法，業務邏輯等。
由於通信的兩端都在我們的控制之中，所以我們並不是真的需要使用肥皂，但是爲了所有的清晰和調試，安全和一般的安心，SOAP是理想的。
想，如果這是一種方法的人使用，如果有任何的框架存在，使/引導/緩解轉換代理回原來的類型的任務..
或者有其他任何可能的方法。
Marc是正確的，您不能在SOA架構中共享類型。事實上，在SOA中，這是不可取的。
但是你已經決定你不需要SOA，所以你可以共享類型，如果你喜歡。使用「添加服務參考」時，只需單擊「高級」按鈕，然後選擇您希望在客戶端和服務之間共享的一組類型。
當然，這會將您的客戶端和服務緊密地綁定在一起，並且會失去SOA的其他好處，但它並不比使用COM更糟糕。
您CAN NOT真正的SOA世界中的共享類型（例如類） - 因爲最終真正歸結爲什麼是所有東西都被串行化爲XML流並通過線路發送。另外 - 一端可能是.NET，另一端是PHP或Java--現在我不認爲您的Java客戶端會理解並能夠在您的對象上執行.NET方法。
SOA與「對象遠程處理」不同，它只是不適用於通過網絡實際遠程對象 - 它發送XML消息 - 這就是它所能做到的。它可以來回發送數據，但不能編碼。
如果在你的場景中你控制對話的兩端，當然你可以將所有的業務對象打包成一個共享的程序集（或幾個），然後在你的程序之間物理共享這些程序集服務器和客戶端。在這種情況下，您可以在服務器上序列化一個對象「客戶」，將XML消息發送到客戶端，然後將其反序列化爲「客戶」。但請注意：您發送的所有內容都是客戶的狀態 - 其領域和屬性中的值。你並不是真的發送代碼 - 恰好在線的兩端都可用。
在這種情況下，很多人做的是通過使用例如從客戶對象抽取感興趣的信息到通常被稱爲「CustomerDTO」的「數據傳輸對象」中。例如AutoMapper以便更容易，然後他們在電線的另一端創建一個新的Customer實例，並將數據從DTO複製回「真實」對象。
Marc
在添加服務引用之前，只需將對共享類型程序集的引用添加到客戶端，就可以輕鬆地在客戶端和服務之間共享類型。
你可以找到詳細的方案，但樣本項目：
http://blog.walteralmeida.com/2010/08/wcf-tips-and-tricks-share-types-between-server-and-client.html