2

同じソリューション（異なるプロジェクト）にWCFサービスとクライアントがあります。サービスクラス自体はインターフェイスから継承し、そのインターフェイスはクライアントとサーバー間で（リンクされたファイルを介して）共有されます。クライアントはサービスファクトリを使用してプロキシを生成します。これは、クライアントからサーバー側のプロジェクトを参照せずに、2つの側をリンクするための非常に優れた方法であることが証明されています。

サービスメソッドの1つは、DataContract属性とDataMember属性を含むオブジェクトを返します。最近まで、このクラスはクライアントにもリンクされていましたが、サーバー側のロジックはコンパイルシンボルを使用してクライアントから除外されていました。

これもインターフェースに変える方が賢明だと思いました。しかし、クライアントからサービスメソッドが呼び出されるたびに、次の例外が発生します。

基になる接続が閉じられました：存続することが期待されていた接続がサーバーによって閉じられました。

その内部例外は次のとおりです。

トランスポート接続からデータを読み取れません：既存の接続がリモートホストによって強制的に閉じられました。

したがって、簡単な例として、私のサービスは基本的に次のインターフェイスをクライアントと共有します。

public interface IMyData
{
    [DataMember]
    int Id {get; set;}

    [DataMember]
    string Description {get; set;}
}

インターフェイスが動作して返される実際のオブジェクトは、次のようになります。

[DataContract]
public class MyData : IMyData
{
    [DataMember]
    public int Id {get; set;}

    [DataMember]
    public string Description {get; set;}
}

私のサービスのインターフェースは次のようになります。

[ServiceContract]
public interface IMyService
{
    [OperationContract]
    IMyData GetData();
}

実装は次のようになります。

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Single, InstanceContextMode = InstanceContextMode.Single)]
public class MyService : IMyService
{
    [OperationContract]
    IMyData GetData()
    {
        // Get data.
    }
}

すべてが少し意味があることを願っています！私はこれをすべて間違っているのだろうかと思っています。必要に応じて、クラスの共有とサーバー側のみのコードのセクション化に戻りますが、可能であればインターフェイスを使用したいと思います。

何か案は？

4

1 に答える 1

3

DataContractインターフェイスは単にデータを表し、ロジックを表していないため、にインターフェイスを配置するメリットはありません。通常、これらのDataContractは、同じアセンブリ内に配置するServiceContractsか、別のアセンブリをすべて一緒に配置します。これにより、ビジネスロジックがクライアントに公開されるのを防ぐことができます。

于 2012-07-09T19:25:40.113 に答える