私は別のCQRS samples
を見てきましたが、そのほとんどはUnitOfWork
(つまり、の場合はDataContext
)を保存しないコマンドハンドラを使用しています。このようなもの:CQRSコマンドハンドラでUnitOfWorkを保存しないのはなぜですか?
public void Handle(Command message)
{
var course = Mapper.Map<Command, Course>(message);
_db.Courses.Add(course);
}
通常、要求が処理されると、保存(トランザクションコミット)はバックグラウンドで行われます。
私はこのアプローチを多くの主要なCQRSの人たちから見てきましたが、私はその考えを聞いたことがありません。
このアプローチの最大の問題は、ハンドラ呼び出しが返された直後にエンティティIDを取得する必要がある場合です(かなり発生します)。それを回避する方法は明らかです(つまり、Guidを使い、データベースから一意のIDを事前に要求するなど)が、不器用に見えます。
しかし、このアプローチの利点は何ですか?理論的には、リクエストごとに複数のハンドラがある場合に、複数のデータベースラウンドトリップを行わないようにすることができます。しかし、それはあまり起こりません。私の頭に浮かぶもう1つの利点は、そのルーチンにSaveルーチンを入力する必要がなく、自動的に実行されるということです。それはちょっといいですが、それはId生成の問題を過大評価していますか?
私はすべてがリポジトリで少し意味をなさないように感じます。私たちがDataContextを使って直接作業しているとき、私たちはドメインで作業していないので、データストアを変更します。そして、私たちは最後のステップ(私たちが修正したものを保存する)をしないで、ドメインオブジェクトの操作を分離してデータストアで作業するふりをします。 – SiberianGuy