列挙型と構成ファイル

Question

テーブルのレコードに基づいてビジネスロジックを実装する必要があります。我々は2つの選択肢がある。

テーブルの各レコードのコードに列挙型を作成し、コード内で列挙型を読み取りレコードと比較して、次にどの論理が来るのかを判断します。このシステムの欠点は、テーブル内でキーが変更された場合（たとえば、オートナンバーフィールドで）、変更を反映するためにアプリケーションを再コンパイルする必要があることです。

これを実行するもう1つの方法は、テーブル内の各レコードの構成ファイルに変数を格納することです。コードはconfig変数と読み取りレコードを比較して、次に来るロジックを決定します。このシステムのドローバックは、設定ファイルを操作してアプリケーションの動作を停止させることです。

この問題のプログラミングパターンは何ですか？

Answer 1

これをまとめてデータベースに格納して、次に表示されるビジネスレコードテーブルを教えてください。

申し訳ありませんが、私は良い答えを与えることはできません。あなたのビジネスロジックが何をしようとしているか、これらのレコードがどのような順序であるかについての詳細が必要です。

Answer 2

私はあなたの最初のアプローチを好む。ロジックが、古いレコードを削除するか、新しいレコードを追加するなどして、オートナンバーフィールドへの変更を必要とするほど十分に変化した場合は、新しいパラダイムを反映するようにコードを変更する必要があります。

Answer 3

列挙型は静的で不変である必要があります。列挙型への変更が必要なソリューションがある場合、列挙型は間違った解決策です。

外部設定では、前述の問題が発生するため、必ずしも良い選択ではありません。これを手助けするために、簡単に変更できないように暗号化することができます。

もう一つの方法は、設定ファイルをリソースとして持つリソースdllを作成して、簡単に変更できないようにすることです。変更を行う必要があるときは、リソースdllをコンパイルして、アプリケーション全体ではなく、それだけをデプロイする必要があります。

Scott Langhamさんがデータベース内の構成表を使用して言及しました。これも良い考えです。これはセットアップで可能ですか？

Answer 4

ステートパターンのように聞こえます。私はあなたのアプリケーションにそれぞれの状態（ID、名前）とロジックが関連付けられているテーブルを持っていると思います。状態IDが与えられると、実行する必要のあるロジックが与えられます。正しい状態をインスタンス化する方法を解決する必要があります.ORMを使用している場合は、ディスクリミネータ（この場合は状態ID）を使用できます。