2

人々が次のシナリオをどのように処理するのか疑問に思っています (これはアイデアを理解するための仮説です)...

  • TABLE A (Orders): OrderId, StatusIdなど (ステータス テーブルの外部キー)
  • TABLE B (Statuses): StatusId, Name,等

テーブル B が存在する必要があります (IOW、たとえばステータスの列挙を作成することはできません)。これは、ビジネス ニーズや慣行が変化し、プログラムGetAllOrders()にGetAllStatuses()、GetOrderByStatus(int statusId)、 などのメソッドがあるため、注文ステータス リストを動的にする必要があるためです。ただし、「ハードコードされた」ステータスに継続的にアクセスする必要があるようです。たとえば、注文が最初に作成されたときのステータスは「新規」であり、ユーザーの介入なしでそのステータスに設定する必要があります。おそらく、"処理中" のすべての注文を返す GetUnfilledOrders レポートがあるかもしれませんが、レポートの名前はユーザーが求めているものを暗示しているため、探しているステータスをユーザーが選択する必要はありません。理解していただければ幸いです。

これらのケースで私が行ってきたことはDefaultNewOrderStatus (int)、新しい注文に使用したいステータスの ID に設定する、またはStatusesForUnfilledOrdersReport (int[])使用するステータスのリストを再度設定するなどの設定を作成することです。ステータス「アーキテクチャ」が変更された場合、これらの設定をその場で変更できるという考えです。問題は、使用する必要がある「ハードコードされた」値の数が増えているように見えることです (おそらく、フルフィルメントされた注文を設定するためのデフォルトのステータス、または「オープン」注文の UI ビューを表示するために使用するステータスのリストが必要です。など）とそれに伴い、それらを処理するための設定の数も行います。

他の人がこれらの状況にどのように対処しているかを知りたいです。

4

4 に答える 4

1

あなたの質問の要点をつかんだかどうかはわかりませんが、「ハードコードされた」方法で Business Process Manager を実装しようとしているようです。実際に必要なのは、ステータスの動的リストではなく、実際にはステータスの使用方法のシナリオであるプロセスの動的リストです。さらに、ステータスの変更をトリガーするアクションが必要です。たとえば、ステータスのリストがあるとします。

  1. 新着
  2. 処理
  3. 配達
  4. 終了した

次に、アクションのリスト:

  1. 新しく作る
  2. 処理を開始
  3. 配達に入る
  4. 納品完了
  5. 戻ってきた

これで、プロセスを設計できます。

  • [開始] -> (新規作成) -> 新規
  • 新規 -> (処理開始) -> 処理中
  • 処理中 -> (配送に入る) -> 配送
  • 配送 -> (返品) -> 処理中
  • 配達 -> (配達完了) -> 完了

アプリケーションには、上記で動作する一連のメソッドが必要です (通常はフォーム、一部のウィザードなど)。何かが変化した場合、新しいステータスを追加し、プロセスをコピーして変更すると、アプリケーションはすでにその処理方法を知っています。たとえば、注文のキャンセルに対処する必要があります。アクションに CANCEL を追加し、注文に CANCELLED を追加して、新しいプロセスを作成 (または古いプロセスを変更) し、以下を追加します。

  • 処理中 -> (キャンセル) -> キャンセル済み

要約すると、問題はステータスの変更だけではなく、ビジネス プロセスの変更です。その場合、ステータスだけでなく、動的なプロセスが必要です。それよりも、問題は消えますが、アプリケーションを再構築するか、新しいアプリケーションを構築する必要があります。

編集

報告に関しては、かなり異なる状況です。あらゆるレポートを生成できる一般的なアーキテクチャを準備する方法を見つけた場合、ビジネス インテリジェンスの実際の形式、データ ウェアハウジングの概念などに挑戦することになります。:-)

于 2012-09-17T19:22:19.990 に答える
0

とにかく別のオプションもあります：

具体的なステータス状況を設定できるステータス設定ページを作成するとstatusId、次のようになります。

New status:         [Select a status]
Received status:    [Select a status]
Processing status:  [Select a status]
Complete status:    [Select a status]

'new'そして、これらの設定を、 などのキーで保存します'received'。その後、新しい注文statusIdのステータスを取得して続行できます - name でステータスを参照するかどう'new'かは問題ではありません。'new' statusIdCompleted

于 2012-09-24T08:55:18.873 に答える
0

列挙型を作成します。この列挙型は、ビジネス ロジック用です。データベース クエリから利用可能なステータスのリストを表示することもできます。

StatusId を StatusEnum 値に変換する場合、データベース内の新しい値のケースが必要になります。ただし、New は引き続き New であるため、すべてのロジックは問題ないはずです。新しく作成されたステータスを使用するロジックを記述する必要がある場合は、Enum を更新します。

ステータスのようなものについては、既存の行で StatusId を変更する必要はありません。行が削除された場合、列挙型は問題なく、その値は決して使用されません。他のメンテナンスを行うときは、それを取り外すことができます。

于 2012-09-17T18:56:06.093 に答える
0

これが私がそれを処理する方法です。一般的なシナリオは、int、int をキーとする文字列です。流体リストを ctor の Dictionary に読み込みます。そのため、新しいリストを取得するにはアプリを再起動する必要があるため、fluid を定義します。

    public static Dictionary<int, string> FluidStatus { get; private set; }  // poulate in ctor
    public class FluidBus
    {
        public Int32 ID { get; set; }  // in set need error checking the ID is in range
        public String Status { get { return FluidStatus[ID]; } }  // need to check the ID is in range
        public FluidBus() { ID = 0; } // default
        public FluidBus(Int32 id) { ID = id; }
        // alternative is to pass a reference to Dictionary in the ctor as then  
        // can change out the status without changing the class
    }

実際、私は主に SysName と DispName で使用し、SysName にはスペースを含めることはできません。DispName は、ユーザーに表示されるものです。しかし、同様の XML エクスポートには SysName を使用します。そうすれば、管理者はユーザーの気まぐれに対処し、半静的な名前をいくつか保持できます。

プログラムが使用する必要があるステータスの場合は、毎回 Enum を使用します。SQL 側では、C# では使用されませんが、共通の制約として FK テーブルを使用します。SQL を使用している場合は、名前を検索できます。

于 2012-09-17T19:25:04.417 に答える