1

クライアントがコンストラクターを介してエンティティをインスタンス化できないようにしたいと思います。これらのエンティティ（初期化状態、コレクションなど）の作成にはかなりの量の計画が必要であり、WCFはそのようには機能しないため、代わりに、サーバー側で作成するメソッドを呼び出すように強制したいと思います。エンティティをネットワーク経由で送信します。

クライアント側：

var client = EntityServiceClient("myEndpoint");
var newEntity = client.CreateEntity();

サーバ側：

public Entity CreateEntity()
{
    return new Entity();
}

何か動作していますが、エンティティのデフォルトコンストラクタが使用されている場合は、どういうわけか例外をスローするか、プライベートにします。したがって、以下は機能しないはずです

クライアント側：

var client = EntityServiceClient("myEndpoint");
var newEntity = new Entity();

それは何か可能ですか？

4

3 に答える 3

2

WCFがどのように機能するように設計されているかは実際には異なります。クライアントに関する限り、シリアル化されたオブジェクトには動作ではなくデータのみが含まれるため、DTOではなくエンティティを返送する必要があります。

ただし、将来問題が発生する可能性が最も高いこのアプローチを使用する場合は、サービスを追加するときにクライアントにメタデータからコードを生成させる代わりに、オブジェクトとサービスインターフェイスを別のクラスライブラリに移動して配布できます。参照。

于 2012-10-24T20:05:12.540 に答える
1

クライアント側のクラスは（通常）生成されたプロキシです。サーバー側と同じクラスではなく、モックアップです。

いずれの場合も、クライアントのデシリアライザーはエンティティを再作成できる必要があります。DataContractSerializerは、プライベートコンストラクターを単に無視し、独自のコンストラクターを作成します。

共有タイプのライブラリを使用すると、状況が少し変わります。その場合にできる最善の方法は、ctorinternalを作成し、ファクトリをライブラリに追加することです。

全体として、これは良い考えではないと思います。覚えておいてください。彼のWCFの目的は、オブジェクトではなく、データを交換することです。

于 2012-10-24T19:31:20.500 に答える
0

あなたの質問は私には本当に不明確です-とにかく私はあなたを助け、あなたにいくつかのヒントを与えるようにしています。あなたの場合、ある種の工場が良いアプローチだと思います。

サーバー側アセンブリでEntityServiceClientとを定義します。Entityアクセス修飾子は、ここでEntityコンストラクターを介したのインスタンス化を防ぐことに注意してください。

public class EntityServiceClient
{

    public EntityServiceClient(string endpoint)
    {
      // put here initializing code for your service client.
    }

    public Entity CreateEntity()
    {
        return new Entity(); // May here put your complexe code to initializing a new valid entity
    }
}

public class Entity
{
    internal Entity()
    {

    }
}
于 2012-10-24T19:31:46.807 に答える