データ転送オブジェクトとデータセットを使用する場合

Question

データ転送オブジェクトの使用方法とデータテーブルの使用方法に関する方法論を考え出しています。

私たちのシステムに直面しています問題の例として...

我々は、異なる特性を持つ同じものを表す6つの異なるビジネスエンティティアセンブリを持っています。彼らは、数年の間にさまざまな問題に関係するいくつかの開発者によって作成されています。

たとえば、「自転車」クラスを使用しているさまざまなアプリケーションは、自転車のさまざまな特性に関わっていました。そこで彼らは、関連するプロパティだけを取得してデータを取り込むさまざまなデータメソッドを呼び出しました。

データサービスの1つの移入

• ブランド
• 色

データサービス2つの移入

• 歯車

• タイヤサイズ

それぞれが異なるビジネスエンティティを使用します。明らかにこれはばかげているので、可能なすべてのプロパティの組み合わせに対して新しいクラスを作成することはできません。

私は、これが問題であれば、おそらくORMを使用しているはずであると私に語ります。

しかし、当面はお伝えしたいと思います。

• テーブルから行全体を入力または返す場合は、データベースに一致するDTO/Business Entityを使用します。

• ランダムなプロパティセットを返す場合は、データテーブルを使用します。

誰でもガイダンスを提供できますか？

おかげ

Answer 1

これは、私たちが話しているシステムのサイズによって異なります。これらが本当に別のシステムである場合、同じコンセプトを表示するさまざまな方法で動作する理由があります。 http://dddcommunity.org/discussion/messageboardarchive/BoundedContext.html

このような場合は、通常はAPIレベルで明示的な境界ではなく、データベースを介して異なる境界のあるコンテキスト間で通信している可能性があります。

情報の一部を管理または返すことは、必ずしも別のクラスを使用することを意味するわけではありません。共有クラスは異なるインターフェースを実装することができるので、呼び出しコードは情報のサブセットを処理できます。

Answer 2

私はそれをシンプルに保ち、常にDataSetを返します - 要するに、一般的なDTOとDataSetを使用します。柔軟性があり、タイプセーフで、利用可能です。あなたが非常に毛深いネストされたオブジェクトモデルに入らない限り、DTOはあなたに何も買わないでしょう。

Answer 3

エンティティをデータベースから分離するのに問題はありません。これはEntity Frameworkで簡単に行うことができます。異なるプロパティセットを持つ同じテーブルまたはテーブルセットに複数のエンティティをマッピングさせることができます。

今のところ、一般的な「自転車」の定義を標準化しない理由もありません。データサービス1がブランドと色だけを更新したい場合、UpdateBrandAndColor操作を行うことができます。エンティティ全体、そのID、ブランド、色だけを渡す必要はありません。 #gearsやタイヤサイズと同じです。

ただし、GetBicycle操作から返された1つのBicycleエンティティタイプのみが必要です。