DTOをビジネスオブジェクトとして使用することは、最善の決定ではありません。私の経験から、通常、オブジェクトがすべてのレイヤーで同一である場合、おそらくどこかのアーキテクチャに問題があると言えます。
実際のビジネスシナリオでは、サーバー上のビジネスロジックとクライアント上のビジネスロジックが同じコンテキストを持ち、同じオブジェクトで動作することはほとんどありません。そして、それらがデータベースとまったく同じ構造を持っている場合...うーん...データ駆動型アプリケーションのように聞こえます。
しかし、クライアントが一部のデータにアクセスし、それを変更して保存し直すときにデータ駆動型アプリケーションである場合、おそらくこの複雑な階層化は本当に必要ないのでしょうか。シンプルに聞こえるので、シンプルにしましょう。データ駆動型アプリケーションの場合は、データベース上にWCF DataServicesコンテキストを作成し、DTOやマッピングなどを考慮せずにWCF経由でデータにアクセスするだけで、すべての汚い作業を実行できるようにしてください。
データ駆動型アプリケーションでない場合は、サーバー側に複雑なビジネスロジックがある可能性があり、このビジネスロジックは通常、そのコンテキストのみを意味するオブジェクトで動作します。これらのオブジェクトをUIまでプッシュするのは意味がありません。
代わりに、UIは、システムに何かを実行するように要求するために、おそらくサーバーにコマンドを送信します。たとえば、AccountDTOをロードする代わりに、「DisableAccount（id = 123）」コマンドを送信し、IsEnabledフラグをfalseに変更して、プッシュバックします。ビジネスロジックがある場合は、アカウントを無効にする方法や他のことを行う方法を知る必要のないクライアントからのそのようなコマンドによってトリガーされる可能性があります。それはただ知っていて、システムに何かをするように命令することができます。
したがって、このシナリオでは、クライアント（UI）はサーバーと同じオブジェクトを必要としません。ユーザーに表示するためにいくつかのデータが必要になる場合がありますが、ビジネスロジックではなく、クライアントのビューにとって意味のある形式になっていることは間違いありません。おそらく、何らかの形で組み合わされた、いくつかの非正規化されたデータが含まれます。
たとえば、User for UIは、UsersテーブルにマップされたDTOではありません。これは別のDTOであり、さまざまなテーブルのユーザーデータと統計を含み、何らかの方法で処理されます。クライアントはサーバーのデータストレージの内部構造を知る必要がないため、公開する必要はありません。関連するデータを取得し、適切なコマンドを送信します。それだけです。
これをすべて言って、それはあなたが行う二者択一ではないことを強調する必要があります。単純な機能の場合は単純なアプローチを使用でき、ビジネスロジックを持つことが理にかなっている機能の場合は他のことを行うことができます。
すべてに1つを選択する必要はありません。したがって、「The Way」であるという理由だけで、常に3つの類似したオブジェクトを作成する必要はなく、常にエンティティをUIに渡す必要もありません。しかし、あなたがしなければならないことは、コンテキストを明確に分離し、どのアプローチが使用されるかを定義することです。
80％では、おそらく単純なもの（WCF DataServicesなど）になり、何もする必要はありません。多くの操作では、データを変更したいだけなので問題ありません。
しかし、実際のビジネスロジックが存在する他の20％（アプリケーションの「コア」）では、オブジェクトだけでなく、レイヤー間の責任についても、この種の分離が必要になる場合があります。