2

私の最近のプロジェクトでは、そのプロパティがさまざまなユーザーによって段階的に完了するクラスがありOrder、各ユーザーは部分的に完了した注文を次のユーザーに参照するため、たとえば、BOM （Bill of Material）が指定されている場合は、生産を計画している場合は、などです。 OrderStatusOrderStatusNewStatusStatusBOMAttachedStatusStatusPlannedStatusここに画像の説明を入力

また、各ステップでいくつかの検証ルールを に適用する必要があります。たとえば、ユーザーは( ) を作成するときにOrder顧客名を指定する必要があります。OrderNewStateOrderPlannedStatus

そこで、State Design パターンを使用して状態を管理し、Factory Design パターンを使用して検証をチェックすることにしました。

ここに画像の説明を入力

public static class StatusFactory
{
    static public IStatus CreateOrderStatus(Order order)
    {
            //check statuses from last to first   
            if (order.PlanningDate != null)    
               return new PlannedStatus();
               ....            
            if(order.CustomerName != string.Empty)  
               return new OrderItemNewState();
    }
}

そして、私が私のを保存したいとき、私はそれを設定するためにcurrentOrder呼び出します:StateFactory.CreateOrderStatus(currentOrder)Status

public void Save(Order order)
{
   order.Status = StatusFactory.CreateOrderStatus(order);
   UnitOfWork.SaveChanges();
}

私の場合、この方法は正しいですか？より良い解決策はありますか？

4

1 に答える 1

1

それはうまくいきますが、あなたのデザインとあなたが説明したことにはいくつかの問題があります.

  1. 各状態への移行では、ルールを起動して入力オブジェクトを検証する必要があります - あなたの設計はこれをカバーしていません
  2. 状態の変更はどこでも管理されていないため、そのロジックを StateFacotry または他の場所に分散させ、手動で処理します。

私がしたいことは、単純に Transition メソッドを呼び出してターゲット State を提供できる StateMachine クラスを作成することです。トランジション メソッドは State からクエリを実行して、検証が必要なルールを確認し、検証メソッドを呼び出します。成功すると、オブジェクトの状態が変更されます。

この設計の利点:

  1. StateMachine は状態のグラフを登録できます (S1->S2,S3 | S2->END | S3->S4 | S4->END)
  2. 状態遷移は、レジスタ グラフに基づいて自動的に発生し、
  3. 各州は、移行を成功させるために満たす必要のあるルールは何かを知っています。(自己記述的)
  4. StateMachine は、状態がどのように遷移しているかのロジックを公開しておらず、すべてがその実装にカプセル化されています
  5. StateMAchine は実際のオブジェクトとは無関係であり、すべての遷移ロジックと検証の実行を管理します (完全な検証エンジンをステート マシンに簡単に統合できます)。
于 2013-09-18T04:11:43.153 に答える