問題タブ [command-query-separation]

同時実行の競合をアプリケーション層に伝達する場合、コマンドクエリ分離の原則を尊重する例外を使用する代わりの方法はありますか、それとも例外は（例外をサポートする言語で）私たちが持っている最良のメカニズムですか？

私のアプリケーションの内部には、特定の高レベルのメソッドを呼び出すときに数層下で実行する楽観的ロックロジックがあります（私の場合、カスタムデータアクセス層を使用していますが、確かにオープンですORM実装がこれをどのように行うかを聞く）。アプリケーションが対話する高レベルのメソッド呼び出しは、次のようになります。

他の誰かが作業中のデータを更新したときに、Webアプリケーションのユーザーに通知できるようにする必要があります。

データを変更するメソッドから値を返したくありません。そのため、過去に例外をスローしましたが（.NETデータアダプターAPIは、競合を検出するとDBConcurrencyExceptionをスローします）、同時実行の競合は、常識的な方法では例外ではありません。それらは現実のものです。アプリケーションのワークフローの予測可能で期待される部分です。Eric Lippertの分類法では、それらは外因性の例外として適格ですか？

私は現在、変更の摩擦を最小限に抑える、保守性の高いシステムのアプリケーション設計のベストプラクティスを（かなり高いレベルで）調査しています。「データ層」とは、データベース設計、オブジェクトリレーションマッパー（ORM）、および一般的なデータアクセステクノロジを意味します。

あなたの経験から、データ層の開発に関してよくある間違いと悪い習慣は何であると思いますか、また、データ層を開発者にとってより良い場所にするためにどのような対策を講じ/実施しましたか/または推奨できますか視点？

回答の例には、次のようなものがあります。低速で、拡張性が低く、拡張可能なデータ層の最も一般的な原因は何ですか。+この問題を解決するために（設計またはリファクタリングで）どのような対策を講じることができますか？

私はここで戦争の話と、公に入手可能なガイダンス文書とサンプルに組み込むことができるいくつかの現実世界のアドバイスを探しています。

CQS の原則について読んだことがある人は、次のことを知っています。

CQS では、すべてのメソッドは、アクションを実行するコマンド、または呼び出し元にデータを返すクエリのいずれかである必要がありますが、両方である必要はありません。

ASP.NET MVC アクションについて言えば、CQS は、このようなアクションを持つべきではないことを示していますか?

このメソッドは、システムの状態を変更し、現在の状態を返します。ここで CQS が適用される場合、2 つの別個のアクションが必要です。1 つは新しい注文を挿入するためのもので、もう 1 つはシステムのシステムを取得するためのものです (最初のアクションが正常に完了した場合、クライアントから呼び出される必要があります)。ただし、これはプログラミングを複雑にします。

これについてあなたの意見を知りたいです。

モッシュ

ウィキペディアのコマンドクエリ分離の定義では、次のように述べられています

より正式には、メソッドは、参照透過性があり、したがって副作用がない場合にのみ値を返す必要があります。

コマンドを発行している場合、この定義では関数はデータを返すことができないため、そのコマンドが成功したかどうかをどのように判断または報告する必要がありますか？

例えば：

この呼び出しにはコマンドとクエリの両方が含まれていますが、クエリ部分はコマンドの結果です。次のように、コマンドパターンを使用してこれをリファクタリングできると思います。

しかし、これはコードのサイズと複雑さを増しているように見えます。これは、リファクタリングするための非常に前向きな方向ではありません。

操作の結果が必要なときに、誰かがコマンドとクエリの分離を実現するためのより良い方法を教えてもらえますか？

ここで何かが足りませんか？

ありがとう！

注：Martin Fowlerは、 cqsCommandQuerySeparationの制限について次のように述べています。

Meyerは、コマンドとクエリの分離を絶対に使用するのが好きですが、例外があります。スタックをポップすることは、状態を変更する修飾子の良い例です。Meyerは、この方法は避けられると正しく言っていますが、これは便利なイディオムです。ですから、私はできる限りこの原則に従うことを好みますが、私はそれを破ってポップを得る準備ができています。

彼の見解では、いくつかのマイナーな単純な例外を除いて、コマンド/クエリ分離に向けてリファクタリングすることはほとんどの場合価値があります。

についてどう思いますか

クリーンコードでは、これはコマンドクエリ分離の違反と見なされます。しかし、コマンドDoSomething（）の何かがうまくいかなかったかどうかをどうやって理解できますか？SQLコマンド（例：void Delete（Table））はどうですか？そのテーブルが存在したかどうかをどうやって知ることができますか？

ありがとう。

変更されたオブジェクトを返すことができる関数、または単にインスタンスを変更する関数の Python での命名規則は何でしょうか。

両方を実装したいとしましょう。関数にどのように名前を付ける必要がありますか?

例: crop()Image オブジェクトの関数が必要だとします。crop()コピーを返すcrop!()場合と元のインスタンスを変更する場合に使用する必要があるため、Ruby は簡単でした。

.NET WCF Web サービスを呼び出す .NET WPF スマート クライアントがあります。Web サービスはほとんどの作業を行い、少量の情報をクライアントに返します。そのため、ブラウザとまったく違うわけではありません。

クライアントは Web サービスを呼び出し、その時点で Web サービスは何らかの作業を行い、「結果」オブジェクトを返します。物事は複雑になりつつあります。これは、私が CQS を適用していないためだと思います (この時点では、CQRS ではなく CQS について話していることに注意してください)。物事をリファクタリングして簡素化し、CQS を取り入れたいと思います。そうするために、この時点で WCF コントラクトを喜んで変更できます。

ただし、これは、クライアント アプリケーションが「コマンド メッセージを送信」し​​ (つまり、Web サービスでコマンド メソッドを呼び出す)、その後、次に何をすべきかを「クエリ」する (同じ Web サービスで別のメソッドを呼び出す) ことを示唆しています。 . これは不必要だと思います。request/response-style は非常に一般的なスタイル (ブラウザーのことを考えてください) であり、考えてみると、技術的に CQS を破っています。私の場合、Web サービス内で操作を提供し、CQS に従っている場合、2 つの間の実際の Web サービス呼び出しについてシステムを少しごまかしても大丈夫だと思います。

これは受け入れられますか？

私は流暢なインターフェースを書き始め、マーティン・ファウラーが流暢なインターフェースについて書いた古い作品を見てみました（彼とエリック・エバンスがこの用語を作り出したことに気づいていませんでした）。作品の中で、マーティンは、セッターは通常、構成または作業中のオブジェクトのインスタンスを返すと述べています。これは、CQSの違反であると彼は言います。

中括弧の世界での一般的な規則は、修飾子メソッドが無効であるということです。これは、CommandQuerySeparationの原則に従っているためです。この規則は流暢なインターフェースの邪魔になるので、この場合は規則を一時停止する傾向があります。

したがって、私の流暢なインターフェースが次のようなことをする場合：

これは本当にCQSの違反ですか？

更新ログの警告とエラーを別々の動作として表示するために、サンプルを分割しました。

コマンドクエリ分離のアイデアは気に入っていますが、エンティティを追加しているMVCコントローラーアクション内でそれを使用する方法がわかりません。追加後に新しいエンティティのIDが必要になります。

たとえば、以下の簡略化された例では、サービスを使用して新しいアイテムを作成します。

ただし、新しいアイテムを表示するアクションにリダイレクトするときは、データベースから取得できるように、新しく作成されたアイテムのIDを知る必要があります。そのため、新しく作成されたアイテム（または少なくともそのID）を返すようにサービスに依頼する必要があります。

純粋なCQSでは、コマンドには戻り値がないため、上記のパターンは無効になります。

どんなアドバイスもありがたく受けました。