1

MSの例から取り出して少し変更した、この単純な契約があるとします。

  [ServiceContract(SessionMode = SessionMode.Allowed)]
        public interface IService
        {
            [WebInvoke(Method = "POST", UriTemplate = "", ResponseFormat = WebMessageFormat.Xml,
                RequestFormat = WebMessageFormat.Xml),
             Description(
                 "Adds a customer to customers collection. The response Location header contains a URL to the added item.")]
            [OperationContract]
            Customer AddCustomer(Customer customer);

            [WebInvoke(Method = "DELETE", UriTemplate = "{id}"),
             Description(
                 "Deletes the specified customer from customers collection. Returns NotFound if there is no such customer.")
            ]
            [OperationContract]
            void DeleteCustomer(string id);

            [WebGet(UriTemplate = "{id}"),
             Description(
                 "Returns the specified customer from customers collection. Returns NotFo`enter code here`und if there is no such customer.")
            ]
            [OperationContract]
            Customer GetCustomer(string id);

            [WebGet(UriTemplate = ""), Description("Returns all the customers in the customers collection.")]
            [OperationContract]
            List<Customer> GetCustomers();

            [WebInvoke(Method = "PUT", UriTemplate = "{id}"),
             Description("Updates the specified customer. Returns NotFound if there is no such customer.")]
            [OperationContract]
            Customer UpdateCustomer(string id, Customer newCustomer);
        }

webhttp RESTおよびnettcpバインディング（セッションを使用）を介して公開するには、このコントラクトが必要です。

私のケース（契約）ははるかに難しいので、両方の目的で1つの実装を使用するかどうかを理解し、webhttpbinding呼び出しとnettcpbinding呼び出しを何らかの方法で区別するか、エンドポイントごとに異なる実現を提供する必要があります。

前もって感謝します

4

1 に答える 1

2

SOAP/WS-* (nettcpbinding) と REST など、異なるアーキテクチャ スタイルを混在させる必要はないと思います。正しい実装では、違いがあります。また、1 つのサービスでこのようなスタイルを混在させる場合、サービス メソッドのロジックには、どのモードで作業しているかを判断するために複数の if-than または switch ケースが確実に含まれます。これは、HTTP または WCF コンテキストの両方を使用する場合にも問題になる可能性があります。

別々のエンドポイント (コントラクト) を作成することをお勧めします。1 つは REST 用、もう 1 つは WS-*/SOAP 用で、それぞれのアーキテクチャ スタイルに従います。

それらの間でロジックを共有するには、ビジネス ロジックを別のレイヤー (クラス) にカプセル化すると、REST または WS-* 固有のロジックとビジネス ロジックを混在させることなく、単純に再利用できます。

単純な CRUD 操作を扱う場合は、データベースに基づいて REST/OData エンドポイントを生成できる WCF Data Service の使用を検討してください。

コメントからのUPD:ステートレスRESTサービスを使用できますが、セッションを「エミュレート」できます。例として、ユーザーを認識して区別するために、各リクエストの特別な 'Authentication' HTTP ヘッダーでユーザー認証結果トークンを渡すのが一般的です。このようなヘッダーは各リクエストで渡され、実際に承認されたユーザーとのセッションをエミュレートします。したがって、セッションが 2 つのエンドポイントの 1 つの理由にすぎない場合、この問題はそのうちの 1 つだけで解決できます。

于 2012-05-04T09:14:20.707 に答える