3

チェックするルールが多数ある財務アプリケーションがあります。ファイルはSQLサーバーに保存されます。これは C# を使用した Web アプリケーションです。これらのルールについて各ファイルをチェックする必要があり、考慮すべきルールは何百もあります。これらの規則は、数週間から数か月ごとに変更されます。私の考えは、これらのルールを xml ファイルに保存し、コード ビハインドで xml を読み取り、ファイルに対して動的に SQL クエリを生成することでした。テスト目的で、これらのルールをハード コーディングしていますが、これらのルールの変更により対応できるアーキテクチャに移行したいと考えています。xml はここに行くには良い方法だと思いますが、以前に同様の道をたどったことのある人からのアドバイスをいただければ幸いです。

各ルール チェックの複雑さは小さく、一般に、「If A && B && (C || D)」のような単純なステートメントに過ぎません。その後、出力文字列をログ ファイルに書き込みます。

私の考えでは、xml (A && B && (C || D)) でクエリをコーディングし、xml のそのノードに文字列を添付します。クエリが成功した場合は文字列が書き込まれ、クエリが失敗した場合は文字列は書き込まれません。

考え？

コメントに応えて、より具体的な例を次に示します。データベースには「資産」と呼ばれるエンティティがあります。当座預金、貯蓄、401k、IRA など、多数の資産タイプがサポートされています。チェックするルールの例は次のとおりです。 . その例は、本当に単純なケースです。

また、特定のプロパティ タイプを持つ特定の状態にあるクライアントのファイルを拒否するルールが短期間適用される、より複雑で動的なケースもあります。古典的な例は、フロリダのコンドミニアムを許可しないことです。このルールはしばらくの間存在し、その後削除されます。

ルールのプールは、大手貸付銀行の裁量に基づいて常に変化しています。これらのルールの変更は、サイトのソース コードの外で行う必要があります。したがって、xml を使用し、C# で xml を解析してルールを動的に適用するというアイデアは、私のアイデアでした。これは、アプリケーションとそのニーズを明確にするのに役立ちますか?

4

1 に答える 1

0

SQL を含むテーブルを作成できますか? 次に、SQLに特定の構造を返すようにすることで、少し形式化できます..

したがって、チェックの表は次のようになります。

id  |  chechGroup  |  checkName      |  sql            |
 1  | '401k checks'| '401k present'  |select           |
                                     |   '401k present'|
                                     |   ,count(*)     |
                                     |   ,'remove 401k'|
                                     |from             |
                                     |    assests      |
                                     |where            |
                                     |   x like '401k%'|

sql 列の sql が次のような形式を返すことを主張できます。

ruleName      |   count  | comment
'401k present'|   85     |'remove 401k'

さまざまな種類のルールを使用できます..これと同様のことを行った場合、合計は返されませんでしたが、代わりに次のようなものが返されました。

table     |   id      | ruleBorken     |  comment
'assets'  |   1       | '401k present' | 'remove 401k'

これは明らかに次のようなクエリになります。

select
  'assets' 
  ,id
  ,'401k present'
  ,'remove 401k'
from 
  assets
where
  x like '401k%'

これにより、集約関数がレポート (ssrs など) によって実行されるインタラクティブなレポートの生成が容易になり、問題の記録にドリルダウンできます。

ルールを検証するクエリは、クエリを選択して EXEC を使用して実行するストアド プロシージャ内で実行することも、アプリケーション コードから 1 つずつ実行することもできます。

一部の列 (例: ルール名) は入力できますが、ストアド プロシージャまたはコードを呼び出します。

この例のコメントとルール名は基本的に同じですが、コメントを分けてそこに case ステートメントを入れると便利です。- たとえば、401k がある場合に空白であってはならないフィールドなど、検証ルールに失敗した場合、コメントに欠落しているフィールドを示す case ステートメントを含めることができます。

エンド ユーザーまたは非開発者にルールを作成してもらいたい場合は、コードで where 句を生成し、ユーザーがテーブル、ルール名を選択して、何らかのインターフェイスを介して where 句を生成できるようにする方法を検討し、それをルールに保存できます。テーブルとあなたは行ってもいいです。

すべてのルールがセット形式を返す場合、すべてのルールに対して 1 つのレポート テンプレートを持つことができます。同様に、ちょうど 3 種類のルールがある場合は、3 つの戻り形式と 3 つのレポート形式を持つことができます。基本的に、結果構造を形式化するのが好きです。他の場所でより多くの再利用が可能になるため

于 2013-09-11T09:41:39.913 に答える