4

私はDDDとOOの原則に不慣れですが、知識が不足していることをお詫びします。

CustomerDTOクラスとCustomerクラスがあります。

すべてのフィールドとプロパティをDTOクラスに格納し、 Customerクラスの基本クラスとして使用します。

DTOを使用する主な目的は、それをViewに渡すことです。プロパティが重複しないように、 Customerクラスで拡張しました。

これを行うのは正しい方法ですか、それともより良いOOソリューションがありますか？

AutoMapperについて読みましたが、別の解決策があるかどうか知りたいです。

どんな種類の助けにも感謝します。

4

4 に答える 4

6

私は個人的にこのアプローチを見たことがありません。DTOを使用する理由は、DALとbizレイヤーの間で懸念を分離するためです。これにより、副作用を最小限に抑えながら、ビジネスレイヤーとDALを独自のペースで変更できます。あなたがしなければならないのは、DTOとDOの間のマッピングを変更することだけです。DTOからDOを継承する場合、DTOを持つことの意味は何ですか？

クイックアンサー：DTOからDOを継承しないでください。今は簡単かもしれませんが、将来的にはメンテナンスの悪夢になるかもしれません。

PSオートマッパーを恐れないでください。その比較的使いやすい。

于 2012-06-26T13:51:48.330 に答える
2

これは悪い考えです。ここに2つの理由があります（おそらくもう少しあります）理由は次のとおりです。

  • ドメインオブジェクトは、トランザクション用に特別に構造化されています。すべてのプロパティへのパブリックアクセスを提供するべきではありません。それらには、行動の目的を提供するプロパティのみが含まれている必要があります。DTOの目的は1つです。それは、データをコンシューマー（UI / Webサービス/メッセージシステムなど）に提供することです。たとえば、顧客のDTOには、顧客が行った注文の数と、顧客が費やした合計金額を提供するプロパティが含まれている場合があります。ただし、ドメイン側では、この注文情報は注文トランザクション用に特別に調整された別の注文集計に保存されるため、顧客集計にはこの情報が含まれない可能性があります。
  • DTOは、ゲッターとセッターがたくさんあるばかげたPOCOです。ドメインオブジェクトがすべてのプロパティにセッターを持つことを許可することは非常に悪い習慣です。操作はアトミックであり、その意図を説明する明示的な名前を持つメソッドによって提供される必要があります。この質問への答えはこの点を説明しています。
于 2012-06-27T08:54:40.203 に答える
0

拡張回答：

誰もそんなことをしないと盲目的に言わずに、この状況を分析してみましょう。

DTO-データのみを含み、境界間でデータを転送する構造です。

ドメインモデル-ここでのキーワードは「モデル」です。これは、ドメインの問題を解決するためのドメインの抽象化です。オブジェクト指向の観点からは、それは単純なクラスです。それを分解すると、純粋なデータ（DTO）と、純粋なステートレスな動作（DDD用語でのサービスまたはドメインサービス）になります。

次に、MVVMパターン、特にVM部分を例にとってみましょう。ビューモデル-ここでもキーワードは「モデル」であり、問​​題を解決するビューの抽象化です。人々がそれを実装する方法はたくさんあります。ドメインオブジェクトをラップするもの、変換を行うもの、DTOをラップするものがあります。ここでのポイントは、ビューモデルはビューのドメインモデルであり、他のモデルとほとんど同じであるということです。では、なぜ人々はドメインモデルを実装する方法を制限するのでしょうか。

ここで、DTOとドメインモデルに戻ります。上で述べたように、ドメインオブジェクトをDTOとサービスに分解できます。ドメインオブジェクトをDTOの動作ラッパーと考えてみましょう（MVVMがよく行うように）。それが私たちを導くところ：

  • まず、OOのカプセル化を解除します。オブジェクトデータが誤って使用されるのを防ぐため、これは悪いことです。誰かがドメインオブジェクトデータ（DTO）を直接操作して、モデルを無効な状態にする可能性があります。これは巨大です。
  • オブジェクトスロー境界、Webサービス、シリアル化、クローン作成を簡単に転送でき、データパーツを切り離して、データストレージまたはWebサービスに渡すことができます。これは分散システムにとっては巨大です。

続けましょう、カプセル化を破ることは深刻な問題です。必要なのは、ドメインオブジェクトデータが直接操作されないことを保証する方法です。ドメインオブジェクトのみがデータを操作する必要があります。これは、ドメインオブジェクトの外部にある場合に、DTOを不変の読み取り専用オブジェクトにすることで実現できます。

次に、DTO、継承と構成の再利用について説明します。誰かが言った：継承よりも構成を好む、そして私は個人的にこのルールに従う。しかし、あなたはあなたの特定の状況を分析する必要があります。ルールは「優先する」と言っていますが、従わないでください。

元のAsnwer：

私は個人的にそのようなアプローチをあまり見たことがありませんでしたが、この方法は過小評価されており、潜在的に非常に良い可能性があると思います。

私はそのような質問が何度も聞かれるのを見ました、そしてすべての答えは、誰もそのようなことをしないのでこれをしないでください。実験することを恐れないでください。

ライアン・ベネットは彼の答えに次のように書いています。

今は簡単かもしれませんが、将来的にはメンテナンスの悪夢になるかもしれません。

確かにそうですが、将来がない場合や小さなプロジェクトの場合は、ここでYAGNI、TDD、アジャイルのルールを守り、最小限の作業でその仕事をします。

コードは石に刻印して決して触れないものではありません。必要なときにリファクタリングしてDTOを導入したり、オートマッパーなどを使用したりできます。

于 2012-06-27T05:53:30.023 に答える
0

古い質問です。特にDALをビジネスレイヤーから分離することについて、他のいくつかの回答が好きです。ただし、DOクラスをDTOクラスから継承するときに発生する可能性のある具体的な問題について説明します。

C＃やVBなどの.NET言語では、真の多重継承を持つことはできません。つまり、クラスは2つの基本クラスを拡張できません。したがって、DOクラスがすでにDTO基本クラスを拡張している場合は、DOクラスと別のDOクラスの間の継承の可能性を排除しています。

実際にデータを保持するテーブルの外観を無視するか、TPH、TPT、またはTPCのいずれを使用するかを無視して、次のDOクラスがあると想像してください。

Vehicle
Car : Vehicle
Boat : Vehicle

あなたは持つことはできませんCar : CarDto, Vehicle。プロジェクトが複雑でDOクラス間に継承がある場合、これはそれ自体でかなり説得力のある議論です。

最後に、継承と構成のどちらかを選択するときは、「isa」と「hasa」の観点から考えることを付け加えておきます。では、「車はCarDtoです」または「車は車です」という意味は何でしょうか。後者のIMO。

于 2017-05-16T18:34:44.217 に答える