ビジネスルールの保存に構成ファイルまたはデータベースを使用する必要がありますか？

私は最近、Pragmatic Programmerを読んでいます。

詳細は、特に頻繁に変更される場合に、元のコードを台無しにします。ビジネスロジック、法律、またはその日の経営陣の個人的な好みの変化に対応するためにコードを変更する必要があるたびに、新しいバグを導入するというシステムを破壊するリスクがあります。

ハント、アンドリュー; トーマス、デビッド（1999-10-20）。実用的なプログラマー：ジャーニーマンからマスターへ（Kindle Locations 2651-2653）。ピアソン教育（米国）。キンドル版。

私は現在、値のセットからのみ取得できるプロパティを持ついくつかのモデルを持つWebアプリをプログラミングしています（Webアプリのデータは機密ではないため）。

light-> type =球/立方体/円柱

ライトのタイプは上記の3つの値のみにすることができますが、TPPに従って、値を変更して構成ファイルに配置できるように常にコーディングする必要があります。アプリ全体でこれのいくつかの事件があるので、私の質問は次のとおりです。

これらのような値を次の場所に保存する必要があります。

• 構成ファイル：
  'light-types' => array(sphere, cube, cylinder),
'other-type' => value,
'etc' => etc-value

• データベース内の構成テーブルごとに1行の単一テーブル

• 各設定項目のテーブルを持つデータベース（例えば表：light_types;カラム：id、name）

• 他の方法は？

提供された支援/専門知識に感謝します。

私が取り組んでいるほとんどのプロジェクトで同じ問題が生じます。通常、私はこれを行います：

1. 可能な値のセットがすぐに変更される可能性が低い場合、コード内のクラス/インターフェイス定数または列挙型、およびデータベース内の列挙可能なフィールドを使用します。例：ブログエントリの公開の状態：「未公開」、「モデレート中」、「公開済み」など
2. 値はおそらく変更されますが、変更はプログラムロジック（構成ファイル）には影響しません。例：「どのようにして当社のウェブサイトを見つけましたか？」のリスト オンライン購入フォームのドロップダウンリストのオプション。
3. 値は頻繁に変更される可能性が高いか、開発者以外によって編集されることを意図していますが、これらの変更はロジックに影響しません-データベースまたは少なくともユーザーフレンドリーな編集用インターフェースを備えたキー値ストレージ。
4. 値を変更すると、ロジックに影響します。おそらく、システムの再設計（多くの場合、真）が必要か、ビジネスルールエンジンが必要です。私が今まで見た中で最も難しいケースは、同僚が取り組んだ心理テストのコンストラクターでした。各タイプのテストには、単純な追加から正と負の値を持つ複数の特性スケールへの単純な追加、または人間による回答の評価まで異なる独自のスコアリングシステムがあります。このプロジェクトに関するいくつかの議論の後、スクリプトエンジンとしてLuaを使用することになりました。これは、開発者以外の人が新しいテストを作成する能力と完全に競合します（Luaは比較的単純な言語ですが、それを学びます）。

TPPからの引用について。原始的なコードには当てはまると思いますが、実際には、シンプルに始め（KISS原則）、後で必要に応じて機能を追加する（YAGNI）方が良いでしょう。

データがデータベースにある場合、同じDBに「light_types」のテーブルを作成することをお勧めします。これにより、外部キーを使用して、light-> typeがそれらの値の1つにしかなれないという制約を適用できるようになるため、コードが乱れた場合でも、DB内のデータは常に有効になります。

データがDBに保存されない場合、多数の列挙型用にデータを作成するだけではあまり効果がありません。値のハードコーディングを本当に避けたい場合は、構成ファイルをお勧めします。

（ただし、ハードコーディングを避けるために行き過ぎないように警告します。重要なシステムでは、作者が気づいているかどうかにかかわらず、ビジネスのルールと要件についての仮定があります。仮定とソフトコードを絶対にすべて、あなたは基本的に「ルールエンジン」、システム内の一種のシステムおよび/またはメタ言語になり、メタ言語にはたくさんのものがあります作業を保存したり、柔軟性を獲得したりせず、別の言語を作成および/または学習する必要がありました。

現在、既存のルールエンジンを見つけて使用する場合は、（enumを格納する場所の質問に答えるだけでなく）少しの作業が節約される可能性があります。ただし、独自のビルドを行うと、ワークロードが2倍になり、まともなルールエンジンを作成する方法を実際に知らない人によって構築された半ばばかげたシステムになります。

一般に、データにはデータベースを使用し、構成には構成ファイルを使用する必要があります。（名前が示すとおり:)）。データベースに構成を保持することは、懸念事項を分離するのが悪いため、正当化する適切なユースケースがある場合にのみ行う必要があります。

使用する構成の量を決定する際には、バランスを取る必要があります。configファイルは、コードと同じくらいアプリケーションの一部として扱う必要があります。できるだけ簡潔にしてください。アプリケーションが構成の肥大化に苦しむのは非常に簡単で、最終的には魔法の文字列でいっぱいの巨大なxmlファイルになります。

あなたが説明する場合、どのcssファイルを使用するかを定義する構成要素を持つことが合理的です。（要件が変更された場合は、変更することができます）。構成ファイルの各要素のスタイルを構成するのはやり過ぎです