2

私は3つの層で構成された比較的単純なWebアプリケーションを書いています。

  1. フロントエンド：非常に薄いコントローラー
  2. ビジネスロジック：ドメイン固有のサービス
  3. ストレージ：シンリポジトリクラス

上で示唆したように、ビジネスロジックのほとんどはサービス層2にあります。

これらのクラスを作成していると、READメソッドの扱いがWRITEメソッドとは大きく異なることに気付きます。

ServiceクラスのREADメソッド

たとえば、READメソッドには過度に厳密な引数チェックはありません。多くの場合、単純な読み取りの場合、Serviceメソッドは、ほぼ1行でRepositoryメソッドを実装しているだけです。

ServiceクラスのWRITEメソッド

ただし、WRITEメソッドを使用すると、引数のチェックとビジネスロジックの実装が大幅に増えます。実際、私のサービスクラスでは、WRITEメソッドでのみ実際に使用されるRulesクラスに依存しています。READSにもビズロジックがありますが、ロジックはWRITESに対してより厳密です。

READSとWRITESを分離する可能性があるための他の引数

また、サービスクラスを実装してクラス内のメソッドを探すときも、最初にREADとWRITEのどちらを使用するかを考えてから、メソッドを探します。

また、クラスでメソッドを探すとき、READSとWRITESを、「Create」、「Update」、「Get」、「Retrieve」などで始まる任意のメソッド名で区切るのは面倒なようです。

考えられる問題と、分離するのは良い考えですか？

試してテストしたパターンを探していると思います。自分で実装してみることができますが、設計が複雑になりすぎたり、循環参照やロジックの繰り返しなどの問題が発生する可能性があるとすでに感じています。READクラスはWRITEクラスに依存する場合があり、その逆の場合もあります。

4

1 に答える 1

5

コマンドクエリ責任分離、CQRSを参照しているように聞こえます

Udi Dahanには、ここから始めるのに適した記事があります。

また、MSパターンとプラクティスにはオープンソースプロジェクトhttp://cqrsjourney.github.com/があります。これはかなり良い例です。

このパターンの欠点は、特に「比較的単純なWebアプリケーション」を作成している場合、エンジニアリングが過剰になる可能性があることです。

Udiは、CQRSを回避するタイミングと、ほとんどすべての場所でCQRSを使用する必要がある理由について別の記事を書いています。これがお役に立てば幸いです。

于 2012-06-03T03:44:50.097 に答える