私はノーと言うでしょう、そして当然そうです。オブジェクト指向の原則とカプセル化については同意しますが、WCFはSO（サービス指向）の原則を扱います。これをCDプレーヤーとCDの観点から考えてください。CDプレーヤーはサービスです。CDはデータ契約です。オブジェクト指向の原則では、CD自体を再生できるようにするために、CDにPlayメソッドが必要です。しかし、CDを再生することには、データを知ること以上のことがたくさんあります。電子機器、出力ジャックへのインターフェースなどがあります。これらはすべてCDプレーヤー...サービスによって提供されます。そのため、サービスコントラクトにはPlayメソッドがあり、CDをデータコントラクトとして受け入れて、何を再生するか（どのように再生するかではない）を指示します。
コメントの質問の後に編集してください： いいえ、確かに（うまくいけば）そうではありません。最悪の場合、34のサービス契約があり、それぞれに平均6つの方法があります。そして、これは、各クラスのすべてのメソッドがサービス操作として発生しなければならないことが確実な場合にのみ当てはまります。考慮する必要がある2つの側面があります。側面1：サービスの設計。34のサービスコントラクトの代わりに、34のクラスを意味のあるグループにグループ化し、グループごとに1つのサービスコントラクトを作成する必要があります。たとえば、InventoryManagementサービス、SalesOrderProcessingサービス、およびBackOfficeOperationsサービスになってしまう場合があります。これらの各サービスには、ドメインにグループ化されたクラスの範囲に関連するサービス操作（およびデータコントラクト）が含まれています。側面2：クライアントで何が起こっているか。各クラスかどうかを検討する必要があると述べました。■メソッドはWCFサービス操作である必要があります。確かに、クライアントに完全にカプセル化された豊富なビジネスクラスがある場合があります。また、操作をサービス操作として実行する必要がない場合、これらの操作はクライアントドメインでロジックを実行します。問題は、サービスを介してそれらをクライアントに取得する方法です。ここでは、2つの選択肢があります。a）クライアントでインスタンスをインスタンス化し、サービス操作によって返されるDataContractからそのプロパティを設定します。b）CSLAのようなフレームワークで行われるように、サービス操作からオブジェクトを直接返します（DevForceは、WCFサービスを介してビジネスクラスを返すための同様のアプローチに従うと思います）。HTH サービス操作として実行する必要がある場合、これらの操作はクライアントドメインでロジックを実行します。問題は、サービスを介してそれらをクライアントに取得する方法です。ここでは、2つの選択肢があります。a）クライアントでインスタンスをインスタンス化し、サービス操作によって返されるDataContractからそのプロパティを設定します。b）CSLAのようなフレームワークで行われるように、サービス操作からオブジェクトを直接返します（DevForceは、WCFサービスを介してビジネスクラスを返すための同様のアプローチに従うと思います）。HTH サービス操作として実行する必要がある場合、これらの操作はクライアントドメインでロジックを実行します。問題は、サービスを介してそれらをクライアントに取得する方法です。ここでは、2つの選択肢があります。a）クライアントでインスタンスをインスタンス化し、サービス操作によって返されるDataContractからそのプロパティを設定します。b）CSLAのようなフレームワークで行われるように、サービス操作からオブジェクトを直接返します（DevForceは、WCFサービスを介してビジネスクラスを返すための同様のアプローチに従うと思います）。HTH b）CSLAのようなフレームワークで行われるように、サービス操作からオブジェクトを直接返します（DevForceは、WCFサービスを介してビジネスクラスを返すための同様のアプローチに従うと思います）。HTH b）CSLAのようなフレームワークで行われるように、サービス操作からオブジェクトを直接返します（DevForceは、WCFサービスを介してビジネスクラスを返すための同様のアプローチに従うと思います）。HTH