DTOはViewModelではないことを私は知っています。誤用した場合の使用法は同じですが、元の目的は異なります。
ドメインエンティティをリポジトリからサービスに返します。私のサービスでは、表形式のビューの必要性に応じて、エンティティの形状を変更する必要があります。
今、私は対立しています。通常、私のサービスはデータを含むDTOを返しますが、この場合、プレゼンテーション層のニーズに応じてデータが再形成されます。誰かがDTOはViewModelであると言うかもしれませんが、私は自分のサービスからビューモデルを返したくありません。
この場合、DTOはViewModelであり、動作はありませんが、それ以上の動作がない場合はどうなりますか。
ここは何かがおかしい。
やり過ぎのように感じるかもしれませんが、サービスと UI レベルで生成したいものと完全に一致するのがちょうど今かもしれないことを見逃さないでください。これらの 2 つの部分が分離しているが、ほぼ同一であることは、本質的に悪いことではありません。
多くの場合、ViewModel は、計算フィールドや UI 選択のオプションなどをサポートするためにさらに拡張されます。サービス (およびサービスに依存している人) を爆破することなく、その個別のオブジェクトを将来的に拡張する方が常に簡単です。
一方、私はYAGNIをフォローするのが本当に好きです。したがって、このオブジェクトが成長する可能性はないと正直に信じている場合、何かをリサイクルすることは必ずしもひどいことではありません. （より多くのコンテキストがこの呼び出しを行うのに間違いなく役立ちます）。
最後に、その学問に多くの時間を費やさないでください。あなたは達成しようとしていることをかなりよく理解しているようで、唯一の良いコードは出荷されたコードです。テストを書き、できることは分けて、コードを外に出します。オーバーエンジニアリングが原因でプロジェクトが失敗するのを見てきました。
乾杯。
コントローラにPresentationServiceがあり、そのオブジェクトがビューモデルを返す役割を果たしていることをお勧めします。次に、プレゼンテーションサービスは、ドメインサービス、データサービス、リポジトリ、またはデータをビューモデルに集約するために必要なその他のものを使用します。
データベースからの形状が必要な場合はDTOをビューモデルとして使用できますが、そうでなく、他の種類のデータプロジェクションがある場合は、プレゼンテーションサービスを使用することをお勧めします。
あなたの痛みが分かります。私は「リポジトリ」パターンを使用しませんが、私のサービス レイヤーは DTO をコントローラーに返し、ある時点で ViewModel のほとんどまたは少なくともいくつかのプロパティを設定します。これはやり過ぎのように思えることもあり、常に「これが最善の方法か」という疑問が生じます。私が言われたことと調査したことから、答えは「YES」です。