私は CQRS を使い始めたばかりで、フォームで Command オブジェクトをモデルとして使用するのが最も理にかなっていると考えました。DataAnnotations を使用したコマンドのクライアント側検証の一部を利用できます。クライアント側検証により、かなりクリーンになります...
私の質問...これは何か問題を引き起こしますか? コマンドにデフォルトのコンストラクターがない場合、このプロセスは不可能になりますか? コンストラクターが集約 ID を挿入できる独自の CommandModelBinder を作成する必要がありますか?
あなたの考え、私はこのテクニックをどこにも見つけることができません。
DTO とメッセージがシステム (クライアント側とサーバー側の両方) と対話する方法について、タスクベースの UI に関するGreg Young の記事を参照することをお勧めします。
コマンドがユーザー インターフェイスの外観と正確に一致するというセバスチャンの意見に同意します。その結果、おそらく個別の DTO/モデル クラスとコマンドが必要になります。モデルは実際にはシステムのクエリ側の結果であり、システムに送信しているメッセージの正確な複製であってはならないため、これは本当に悪いことではありません。
また、コマンドをモデルから分離することで、コマンド コンストラクターに関する懸念が解消されます。コントローラーは、クライアントから情報を収集し、コマンドを作成して送信します。
CQRS の使用を開始する場合、Greg のサイト (cqrsinfo.com) は非常に優れており、特に彼の6 時間半のビデオが役に立ちます。はい、これは 6 時間半ですが、CQRS とは何かについての素晴らしい紹介と概要です。それは私を大いに助けてくれました。
お役に立てれば！
POST を使用してコマンドをドメイン コマンド ハンドラーに送信することは賢明なようです。ただし、インターフェイスをバインドする正確なオブジェクトである可能性は低いです。インターフェイスのコマンド (マウス クリックなど) は、ドメイン コマンド (ユーザーの作成) になります。GUI は、クエリの結果にバインドされる可能性が最も高いです。
あなたが言及した理由により、基本的にクライアントとサーバー間で送信される dto である View Models を作成します。このようにして、モデルバインディング、データ注釈などのすべての mvc の利点を使用できます。コントローラーでコマンドを作成し、コマンドをサービスバスに送信します。
これは、懸念事項をもう少しうまく分離するのに役立ち、私の意見ではテストが容易になると思います。