7

エンティティの状態の変更に関連するタスクがあります。CQRSそして、それが何かを含むイベントベースのアプローチであるべきか、それともa を使用しState patternてすべてのロジックをエンティティ内に残すことができるかについて、私はかなり混乱しています。

State パターンを使用するドメイン モデル (またはその一部) を示す記事を見つけました: http://www.prowareness.com/blog/?p=1448

注文システムは、私のドメイン モデルに非常に近いものです。だから例は素晴らしいです。しかし、MVCパターンを考慮した良い習慣であり、実装できるかどうか疑問に思っていRavenDB/NHibernateますか?

編集：質問の再考

例に従ってみましょう：

まず、 というドメイン エンティティを次に示しますIdea。

[Serializable]
public class Idea : AbstractEntity<Guid> {
    private static IStateFactory stateFactory;
    private AbstractState state = new InitiatedState();

    [Required, StringLength(150)]
    public String Title { get; set; }
    [Required]
    public String ProblemContext { get; set; }
    public DateTime CreatedOn { get; set; }
    public Guid InitiatorId { get; set; }
    [Required]
    public Decimal InvestmentAmount { get; set; }

    public Boolean IsInitiated {
        get { return this.state.IsInitiated; }
    }
    public Boolean IsRejected {
        get { return this.state.IsRejected; }
    }
    public Boolean IsUnderInitialAssessment {
        get { return this.state.IsUnderInitialAssessment; }
    }
    public Boolean IsConfirmedForImplementation {
        get { return this.state.IsConfirmedForImplementation; }
    }
}

一方AbstractState、

public abstract class AbstractState {
    public virtual Boolean IsInitiated {
        get { return true; }
    }
    public virtual Boolean IsRejected {
        get { return false; }
    }
    public virtual Boolean IsUnderInitialAssessment {
        get { return false; }
    }
    public virtual Boolean IsConfirmedForImplementation {
        get { return false; }
    }
}

ステート ファクトリ インターフェイスは次のように定義されます。

public interface IStateFactory {
    AbstractState GetState(String state);
}

最終的な考えは、メソッドを置くことです：

public void AlterState(String stateString) {
    this.state = stateFactory.GetState(stateString);
}
  1. デザインは大丈夫？短所と長所は何ですか？
  2. 拡張性はどうですか？私の見解では、独自のステート ファクトリを拡張/実装できます。しかし、AbstractStateそれ自体に変化があれば、それに応じてすべてが変化します。

ありがとう！

4

3 に答える 3

3

Nicholas Blumhardt による階層型ステート マシンである Stateless に興味があるかもしれません。その機能に関する私のSOの回答をここで読んでください。これは私のブログの単純なワークフロー プロセッサの例です。現在、パイプとフィルタ パターンで使用していますが、非常にうまく機能します。

編集

興味があれば、RavenDB で Stateless を使用する実装もあります。

于 2012-07-31T22:52:05.397 に答える
2

CQRS と状態パターンはまったく別のものです。状態パターンは、単一のオブジェクトの一連の状態またはステータスを実装する方法を提供しますが、CQRS はアーキテクチャ スタイルです。MVC は状態パターンや CQRS とは関係なく、プレゼンテーション レイヤーのアーキテクチャ スタイルです。NHibernate と組み合わせて状態パターンを使用できますが、マッピングは自明ではなく、カスタム IUserType を実装して、フィールドに基づいて適切な状態クラスにマップする必要があります。RavenDB は NHibernate とは大きく異なり、マッピングはかなり簡単になりますが、完全に異なるデータベース システムです。

于 2012-07-18T00:11:17.803 に答える
1

CQRS は、SQL を使用して管理ツールをサポートし、RavenDB をフロントエンドで検索を実行する場合に使用されます。この架空の CQRS シナリオでは、Sql から RavenDB にデータをプッシュする必要があります。

于 2012-07-18T21:55:54.240 に答える