2

ワークフロー ベースにする必要がある ASP.NET MVC 4 Web アプリケーションを開発します。シナリオは次のようなものです。

シナリオ

ユーザーはフォームを送信して銀行の融資を受けるリクエストを行い、オペレーターはダッシュボードのグリッドでリクエストを見つけ、詳細を確認し、問題がない場合は上司に送信し、修正または完了のためにユーザーに送り返します。そうでない場合は、リクエスト。上司はローンを支払うかどうかを決定します。もしそうで、価格が何かを下回っている場合は資金セクションに送られ、何かを上回っている場合はリクエストが別の上司に送られます。

要件

  • 各状態には、追加の関連データが添付されている場合があります。たとえば、リクエストの送信時に計算されたユーザーのポイントです。
  • どこにいてもリクエストをキャンセルしたり、希望する人にリクエストを渡すことができるプロセス マネージャー (管理者) が存在します。
  • 状態がそれらに沿って移動できる複数の遷移が利用可能である可能性があります。状態は条件をチェックし、1 つの遷移を選択する必要があります。

一方、オペレーターは

  • お互いにリクエストを渡します (許可されている場合)。たとえば、忙しすぎる場合や休暇中の場合 (代用者)
  • リクエストの履歴を確認し、往復で変更されたデータを確認します (バージョン管理)
  • リクエストを次の人に送信する前にメモを書くか、誰かに返します。

質問

上記のシナリオでは、どのテクノロジがより適していますか?またその理由は?

  • ワークフロー基盤
  • ビズトーク

または次のようなライブラリ：

4

1 に答える 1

2

私は何年も BizTalk 開発者であり、BizTalk を使用して同様のワークフローを実装していましたが、これには BizTalk を使用しません。

その理由は、BizTalk で複雑なビジネス ワークフローをモデル化することは、BizTalk が実際にうまく機能すること、つまり高性能のメッセージ ルーティングと変換、およびホスト統合機能に対して嫌悪感を抱くという結論に達したからです。

ただし、これにWFを使用することもありません。MS が WF を不必要に扱いにくくしていると思います。最初のバージョンである WF3 で作業したので、改善されたのかもしれません。しかし、私が知る限り、MS は WF4 以降のステート マシン ワークフローを削除し、現在はシーケンシャル ワークフローのみをサポートしています。

ですから、あなたの質問への回答として、どちらもこの目的には適していないと思います。

ASP.NET MVC、JQuery、および SQL Server 以外のテクノロジ スタックから始めてみませんか。現時点では、これが MS Web 開発標準のようです。おそらく、あなたはすでにこのライセンスを取得しています。

要件を前もって示しているように見えても、リストした要件の一部または大部分が変更または削除される可能性があることに気付くでしょう。

そのため、小さなイテレーションですばやく提供できる 1 つまたは 2 つの主要なユーザー ストーリーから始めて、そのような機能を追加し続けます。他のテクノロジーやフレームワークを検討し始める必要がある段階になったら、その時点で決定を再評価します。この時点で、長時間実行されるプロセスを管理するための別のオプションとして、NServiceBus サガを使用することを個人的に検討します。

計画プロセスの早い段階で技術スタックに関する決定を下すと、多くの点で不利になる可能性があると思います。

申し訳ありませんが、元の質問に直接対応していません。

于 2013-09-26T14:35:03.533 に答える