0

保守が困難になった ASP.NET Web アプリケーションがあり、それを再設計する方法についてのアイデアを探しています。これは、お客様ごとに高度にカスタマイズできる従業員管理システムです。それが今どのように機能するかを説明しましょう：

デフォルトのページには、ユーザーが従業員の作成やタイムシートの表示などのタスクを選択できるメニューがあります。例として、Create Employee を使用します。

ユーザーがメニューから [従業員の作成] を選択すると、選択したメニュー項目に対して動的に読み込まれたユーザー コントロールを含む ASPX ページが読み込まれます。たとえば、従業員の作成の場合、AddEmployee.ascx になります。

ユーザーがコントロールで [保存] をクリックすると、既定のページに移動します。
一部のメニュー項目には複数のステップが含まれるため、ユーザーが複数ステップのフローで [次へ] をクリックすると、フローの次のページに移動し、最終ステップに到達するまで同様に続き、[保存] をクリックするとデフォルト ページに移動します。

従業員の作成フロー (SecurityClearance.ascx など) で追加の手順が必要なお客様もいれば、不要なお客様もいます。

異なる顧客が同じ ASCX ユーザー コントロールを使用する場合があるため、AddEmployee.OnInit でその顧客のフィールドをカスタマイズできます。つまり、特定のフィールドを非表示、読み取り専用、または必須にすることができます。

次の項目は、顧客ごとにカスタマイズできます。

  • メニュー項目
  • 各フローのステップ (ascx コントロール名)
  • 各 ascx の隠しフィールド
  • 各 ascx の必須フィールド
  • 各 ascx に関連するルール。これにより、その顧客のコードで特定のロジックを使用できます。

カスタマイズは、顧客ごとに 7500 行にも及ぶ巨大な XML ファイルに保持されます。

このようにアプリケーションをカスタマイズするために使用できるフレームワークまたはルール エンジンはありますか? 他のアプリケーションは、顧客ごとのカスタマイズをどのように管理していますか?

4

2 に答える 2

3

通常のデータがデータベースに保持されている場合、その顧客固有の情報をすべて xml ファイルに保存する理由がよくわかりません。データベースに移動します。

次に、さまざまな種類のルール エンジンがあります。asp.net を使用していることを考えると、Windows Workflow で少なくともこの一部を確認することをお勧めします。以下をお読みください: http://karlreinsch.com/2010/02/05/microsoft-rule-engines/

ずっと前に、Haley Rules という製品を使用して ac# Web アプリを動かしていました。使用可能な画面から、表示されるフィールド、およびそれらが必要かどうかに至るまで、すべてを制御しました。チームがどのように機能するかを理解するのにしばらく時間がかかりましたが、それが起こると、新しいクライアントを連れてくるのは非常に簡単でした. それ以来、ヘイリーはオラクルに夢中になったが、おそらく最高のオラクルだった。

あなたが興味を持っているかもしれない他のものは、NxBREとnCalcです。NxBRE は、Java 用に構築されたものを移植した実際のルール エンジンです。一方、nCalc 自体はルール エンジンではありません。ただし、単純なブール ステートメントでロジックを表現できれば、非常に高速です。現在、これを使用して、アプリケーションの 1 つでページ フローを駆動しています。

商用のものには次のものがあります: FlexRule、iLog

于 2012-11-14T21:07:57.853 に答える
2

既存のルール エンジン ツールは Web アプリケーションをサポートします。つまり、既にニーズを満たしています。MS ワークフローのような他の「ルール エンジン」を使用することもできますが、IMO では維持が困難な状況で終了することもあります。

登録ポータルがあるとしましょう。一般的なユーザー情報を収集し、データベースに保存します。単純。1 つのクライアントに対して、複数の ASCX とルールを使用して 1 つのプロタルを構築します。次に、別のクライアントに対して、これらの ASCX にさらにルールとコントロールを追加します。このように作業を進めていくと、遅かれ早かれ最終的なストロー クライアントにたどり着きます。当時、コードベースは維持するのが難しく、開発者は多くのルールで自分自身を失いました. それが私に起こったことです。

したがって、私にとっては、どのルール エンジンを使用するかは問題ではありません。

ではどうやって？

私は質問を提起しましたが、答えの1つは私にとって理にかなっています(選択された答えではないと思いました)。この回答で、その男はあなたがどのような会社であるかについて言及しました。あなたの質問では、あなたがどの部門であるか、または開発チームを分離したいですか。

アーキテクト チームに所属している場合は、ルール エンジンを使用してフレームワークを構築します。サンプルポータルとして基本的な登録ポータルを作成します。

カスタマイズ チームに所属している場合は、カスタマイズされたユーザー コントロールを作成します (基本バージョンでこれらのユーザー コントロールを再利用しないでください)。再作成するのは単なる UI です。DAO、BO はユーザー コントロールで定義されておらず、他のレイヤーにあるため、引き続き使用できます。このようにして、他のクライアントのルールを汚染したり、他のクライアントの登録に新しいバグを導入したりすることを心配することなく、クライアント指定のルールを自由に定義できます。

それはあなたの質問に対する答えのようなものではないことを理解してください. とにかく、エンジン ルール ベースのマルチクライアント Web アプリケーションに取り組んだ限定 XP の後の私の考えです。

于 2012-11-15T11:51:28.013 に答える