4

悪意のあるデータセットしかなく、Microsoft アプリケーションがレイヤー間の転送オブジェクトをブロックする場合、データセット/データテーブルまたは DTO/POCO のいずれかになります。私は、DTO/POCO を使用するのが好きなギャングに属しています。

SubSonic、Entity Framework、NHibernate などのマッピング レイヤーのこの突然の波で、お気に入りの POCO を引き続き使用する必要がありますか?? 私はほとんどこれを行い、ASP.net Web フォームを操作するとき、99% の時間は、コントロールと各タイプに固有の機能にバインドするために ObjectDataSource を使用することになります。

この POCO への愛をあきらめて、IQueryables や Entities などを渡し、他の DataSource オブジェクトを利用する必要がありますか??

DTO の代わりにこれらのオブジェクトを使用することの長所と短所は何ですか?? アプリのデザインとパフォーマンスにどのような影響がありますか?

編集:Linq Datasorce や Entity データソースなどの他のデータソースを使用できるようになるのはいつですか?

4

4 に答える 4

7

POCO と DTO は長生きします。それらは軽量で、シリアライズが容易で、強く型付けされ、バインド可能です。それらでパフォーマンスの問題が発生したことはなく、常により高いレベルのコードがよりクリーンになりました。

于 2009-01-09T18:31:25.790 に答える
5

nHibernate または POCO にマップできる別の ORM を使用します:-) 次に、プロデューサーとコンシューマーの間で必要な分離に基づいて、DTO または POCO を渡すかどうかを決定できます。

私が尋ねる質問は、データを Entities / IQueryables にプルしてから DTO に変換するつもりですか? これは、特にサービス境界を移行する予定で、ドメイン モデルを公開したくない場合に非常に有効なパターンです。ただし、トレードオフがあります。データのサイズによっては最小限のパフォーマンス ヒットになりますが、それは測定する必要があるものです。

最近、ドロップダウンリストに一連の組織オブジェクトのリストを表示する必要がありました。組織には、多くのプロパティとその他の子オブジェクトがあります。ドロップダウンに必要なものはどれも、ID と名前、およびいくつかの追加プロパティだけでした...

DB を検索し、nHibernate を使用して DTO のリストを返す HQL クエリを次に示します。

      return CurrentSession.CreateQuery(
            "select new OrganizationListDTO(o.Id,o.Name,o.xxx,o.xxx)" +
            " from Organization i where i.State=:state")
            .SetParameter("state", state)
            .List<IOrganizationListDTO>();

ここでのポイントは、ORM を使用している場合でも、クエリのようなレポートに DTO を活用して、面倒な作業をすべて任せることができるということです。

于 2009-01-09T18:47:49.047 に答える
0

私もこれの交差点にいます。SOAには、テクノロジーの制約に加えて考慮しなければならない他の原則があります。それは、正しい方向に進みたい場合です。私は、この議論をさらに一歩進めて（最初は私を含めて）、ビジネスオブジェクト（BO）を交換する方法について質問する人もいます。しかし、私はこれが最も基本的なSOAの原則の1つである自律性に違反していることに気づき始めました。これを行うと、サービスがビジネスの詳細に突然バインドされます。これは、DataContractと「Entities」の問題と比較するために私が提起したかったシナリオにすぎません。原則はもっと重要だと思います-少しの冗長性（つまり専用のDTO）のコストがあっても。メッセージングの「インフラストラクチャ」を維持するために、このためのアダプタパターンにさらに傾倒しました そして、EDMのような豊富なコンポーネント指向のモデルは別のものです。さらに、この「アダプターパターン」を完全なエンティティサービス候補にすることで、SOAの世界でよりエレガントで、再利用可能で、自律的になります。Thomas Erlは、彼の著書「サービス指向アーキテクチャー（概念、テクノロジー、および設計）」で、この「エンティティ中心のサービス」の概念を優れた方法で説明しています。熟考すべきもう1つのこと：私の「エンティティ」が単一のソースに存在しない場合（つまり、一部がデータベースにあり、一部がテキストファイルまたはスプレッドシートにある場合）はどうなりますか？DTOおよび/または本格的なエンティティ中心のサービスでその余分な努力を受け入れることで、それを隠し、はるかに高い俊敏性を促進することができます。Thomas Erlは、彼の著書「サービス指向アーキテクチャー（概念、テクノロジー、および設計）」で、この「エンティティ中心のサービス」の概念を優れた方法で説明しています。熟考すべきもう1つのこと：私の「エンティティ」が単一のソースに存在しない場合（つまり、一部がデータベースにあり、一部がテキストファイルまたはスプレッドシートにある場合）はどうなりますか？DTOおよび/または本格的なエンティティ中心のサービスでその余分な努力を受け入れることで、それを隠し、はるかに高い俊敏性を促進することができます。Thomas Erlは、彼の著書「サービス指向アーキテクチャー（概念、テクノロジー、および設計）」で、この「エンティティ中心のサービス」の概念を優れた方法で説明しています。熟考すべきもう1つのこと：私の「エンティティ」が単一のソースに存在しない場合（つまり、一部がデータベースにあり、一部がテキストファイルまたはスプレッドシートにある場合）はどうなりますか？DTOおよび/または本格的なエンティティ中心のサービスでその余分な努力を受け入れることで、それを隠し、はるかに高い俊敏性を促進することができます。一部はデータベースに、一部はテキストファイルまたはスプレッドシートに）？DTOおよび/または本格的なエンティティ中心のサービスでその余分な努力を受け入れることで、それを隠し、はるかに高い俊敏性を促進することができます。一部はデータベースに、一部はテキストファイルまたはスプレッドシートに）？DTOおよび/または本格的なエンティティ中心のサービスでその余分な努力を受け入れることで、それを隠し、はるかに高い俊敏性を促進することができます。

ボトムライン：SOAの原則を気にせず、より「アドホック」に開発している場合は、選択してください。しかし、企業またはB2Bの立場にあり、SOAが飼いならすつもりの悪名高い「アドホッククリープ」のリスクを冒すことができない場合は、おそらく、SOAエンティティ中心のサービスを第一級市民として行い、そのように管理します。コンピューティングがどこに向かっているのか（SOA、SaaS、PaaSなど）、およびそれらが共有するパラダイムと原則を検討してください。

于 2009-09-25T23:41:22.073 に答える
-1

ドメインと DTO の並列オブジェクト ツリーは嫌悪感を覚えます。コード ジェネレーターを使用している場合でも、維持する必要のある余分なコードはあまり役に立ちません。レイヤーの純度は売り過ぎだと思います。私はDTOのファンではありません。

于 2009-01-09T19:01:07.570 に答える