1

クライアント向けの助成金申請システムを構築しました。彼らは今、いくつかの簡単なワークフロー機能を求めています（申請書を提出する前に2つの承認が必要です）。

最大限の柔軟性と再利用性を提供する方法でワークフロー要件をエンコードするために使用するデータベース設計について考えました。既存の設計パターンやベストプラクティスがあるかどうかを知りたいと思います。このタイプのシステムにはそこにあります。助言がありますか？

注：これはカスタムASP.NETアプリケーションであり、独自のワークフローソリューションを確実に展開します。コンポーネントを購入したり、このすべてをSharePointなどのプラットフォームに移行したりすることには興味がありません。

4

4 に答える 4

4

WindowsWorkflowFoundationを見ないのはばかげているでしょう。それはまさにあなたが必要とするもののために作られました。

これがASP.NET固有のリンクです。

于 2008-10-23T15:53:38.410 に答える
4

ワークフロー機能が非常に単純であれば、あなたのアプローチで十分です。ただし、次のような追加機能が必要な場合 (または顧客が後で要求した場合):

  • 承認者への注意事項
  • 管理者へのアラート
  • 割り当てのエスカレーションと再割り当て
  • 割り当てのキャンセル
  • ルールベースの割り当て
  • 割り当ての追跡

次に、 Workflow Foundationのようなワークフロー コンポーネントを検討する必要がある場合があります。

ワークフロー パターンへのアカデミックなアプローチはこちらで確認でき、次の 4 つのカテゴリに分類されます。

あなたのケースのより興味深いカテゴリはリソース パターンだと思います。

于 2008-10-23T17:28:46.237 に答える
0

過去にうまくいった解決策の 1 つは、承認グループをメンバーで作成し、単純なルックアップ テーブルとして承認コードを作成し、承認ステート マシンをソフト コード化して、各ステップがアイテムへの承認コードの割り当てから生じるようにすることです。グループメンバー。これにより、グループ メンバーシップを変更したり、承認パスを変更したりしても、何も再コーディングする必要はありません。コード トリガーとエンドポイントを (アセンブリ名 + クラス名 + メソッド名などのリフレクションを介して) 追加して、各ステップで副作用とコミット/通知アクションを実行することもできます。

于 2008-10-23T16:02:27.287 に答える
0

同様のクエリがあります。相互依存性を持つバッチ プロセスのグループがあります。これらのバッチ プロセス用のシステムのようなワークフローに取り組んでいます。

次の 2 つのデザインのうち、どちらが優れていますか。

  1. 各プロセスがデータベーステーブルのステータスとその他の詳細を更新し、他のプロセスがこれらのテーブルをクエリするデータベース主導の設計、または

  2. プロセスがメッセージング キューを使用して相互に通信する JMS またはメッセージング ベースのアプローチ。

于 2008-11-04T03:55:09.810 に答える