私はいくつかのWCFアプリケーションがオブジェクトを「分割」することを選択したことに気付きました。つまり、ビジネスロジックを実行する意味のあるクラスライブラリに加えて、DataContracts/Membersを含むDataObjectsアセンブリをプロジェクトに含めることができます。オブジェクトモデルの設計では、WCFのベストプラクティスはどのようなものですか？
これは不要な抽象化レベルですか？既存のクラスライブラリにDataContract情報をタグ付けしてタグ付けすることには、固有の邪魔がありますか？
また、別として、エラー状態をどのように処理しますか？サービスからの例外（InvalidOperation、ArgumentExceptionなど）が一般に受け入れられていますか、それとも通常はそのレベルですか？
内部ビジネスオブジェクトとデータコントラクト/メッセージコントラクトを分離する主な理由は、アプリの内部変更によってサービスコントラクトが必然的に変更されないようにするためです。バージョン管理されたWebサービス（インプリメンテーションされたインターフェイスのバージョンが2つ以上）を作成する場合、データ契約/メッセージコントラクトオブジェクトのバージョンが2つ以上あるアプリケーションビジネスオブジェクトの単一バージョンが存在することがよくあります。
さらに、複雑なエンタープライズ統合の状況では、標準のデータ形式（データおよびメッセージコントラクト）が複数のアプリケーションによって共有されているため、各アプリケーションが正規のデータ形式を内部オブジェクトモデルにマップする必要があります。
データ契約/メッセージ契約などを分離するためのツールが必要な場合は、MicrosoftのWeb Services Software Factory http://msdn.microsoft.com/en-us/library/cc487895.aspxを参照してください。これにはWCF配管の解決法があります。
excpetionsに関して、WCFはFaultExceptions内のすべての例外を自動的に折り返します.FaultExceptionsはワイヤ形式のフォールトとしてシリアル化されています。
一般的なフォールト例外をスローすることもできます。これにより、シリアル化されたフォールトに追加する詳細を指定することができます。 Webサービスの操作によってスロー断層がその契約の一部であるので、それは操作の宣言に障害を宣言することをお勧めします：
[FaultContract(typeof(AuthenticationFault))]
[FaultContract(typeof(AuthorizationFault))]
StoreLocationResponse StoreLocation(StoreLocationRequest request);
AuthenticationFaultとAuthorizationFaultタイプがシリアル化する追加の詳細を表しており、オーバー送ら両方ワイヤーは以下のようにスローすることができます：
throw new FaultException<AuthenticationFault>(new AuthenticationFault());
詳細を欲しがっている場合は、私は生きていて、このようなものを呼吸しているので、ほとんど生きています。）