これらの値を列挙型に保存すると、何らかの外部データ ソースに保存するよりも多くの利点が得られるということに同意できるかどうかはわかりません。
テーブルを維持し、それぞれの管理モジュールを作成する必要があります
確かに、外部データソースに値を格納すると、アーキテクチャ上のオーバーヘッドがいくらか追加されます。ただし、何らかの ORM を使用してデータ アクセスとコード生成を処理している場合、これは非常に小さな作業です。
「管理モジュール」が何を意味するのかはわかりませんが、ユーザーがオプション自体を管理するためのインターフェースではなく、リポジトリを意味すると仮定します。ユーザーが自分で値を管理する方法がないため、代替手段が値を列挙型に入れる場合、後者が必要になる理由がわかりません。
テーブルの「維持」に関する限り、列挙型に値を追加または削除するよりも、実際にはそれ以上の維持を行う必要はありません。JonH が指摘するように、enum ルートでは、単にデータソースに行を追加または削除するのではなく、アプリケーション全体を再構築して再デプロイする必要があります。私にとって、それはより大きなメンテナンスの負担です。
ビジネス価値にアクセスする必要があるたびに表を読んだ
これらの値はかなり静的であると想定しているため、アプリケーションの起動時にこれらの値をキャッシュして処理するのは簡単なことです。
データベースが事前に入力されていないと、アプリケーションは機能しません
だから何？アプリケーションがデータ駆動型の場合、データベースの展開と構成を展開計画の一部にする必要があります。スクリプトに2 つまたは 3 つINSERTのステートメントを追加すると、展開プロセスがさらに複雑になりますか?
これにより、上記の問題はすべて解決されますが、アプリケーション外のデータベースでレポートを実行する場合、これらの値を SQL で変換する必要があります。
とりわけ、これがこれらの値を外部に保存する最も説得力のある理由です。これらの値がレポートで使用されているという事実は、アプリケーションの範囲外で意味を持つことを意味します。これは、それらが他の場所で必要になったときに、この知識を毎回複製する必要があることを意味します. システムに重複があると、メンテナンスの負担が増え、将来の更新でバグが発生する可能性が高くなります。
最後に、列挙型は、UI 要素へのデータ バインドがより困難になる傾向があります。可能であれば、「きれいな」値の名前をユーザーに表示することは許可されません。代わりに、「UserStoredFile」や「PickAndChooseAnotherEnumValue」などの項目を含むドロップダウン ボックスが表示されます。列挙型の値を個別の文字列に関連付ける以外に (さらに重複があります。上記の段落を参照してください)、列挙型のこの制限を克服する方法はありません。
大したことではないように思えますが、まともな開発者であれば、このような細部に気を配る必要があります。ユーザーエクスペリエンス全体に関心を持つことが重要です。特に詳細指向でない場合は、システム内の UI 以外の場所にも問題がある可能性があります。確かに、この最後の点は主観的なソープボックス型の議論です :)。
これらの値を保存するだけでは、アプリケーションにデータベースを追加することはほとんど正当化されないという意見に同意します。ただし、通常は外部データソースと言っていることに気付くでしょう。これらの値を XML やその他の種類の外部構成ファイルから取得するようにアプリケーションを設定できない理由はありません。ただし、既にデータベースを取得している場合は、すべてを 1 か所に保管することもできます。
編集：
これらのオブジェクトの使用は非常に簡単で、単なるコレクションです。それらは列挙型よりもはるかに自然にデータバインドします。データ駆動型のアプリケーションではこれが重要だと思います。
// Bind a collection of SourceLocation to an ASP.net dropdown list
ddlSourceLocations.Datasource = GetSourceLocations();
ddlSourceLocations.DataTextField = "LocationName";
ddlSourceLocations.DataValueField = "LocationId";
ddlSourceLocations.DataBind();
もちろん、あなたが言及したように、これは確かに列挙型では不可能ではありませんが、通常はそれほど良くありません。
これらの「ビジネス値」を列挙型よりも本格的なオブジェクトにすることでSourceLocation、名前と ID を超えて成長する必要があるという概念が将来に向けてより柔軟になります。
後で「IsRemote」プロパティが SourceLocation に追加され、場所が別のマシン上にあることを示すと想像してみましょう。 SourceLocationは、このプロパティを必要とするルールに対応できるようになりました。
if(myDataObject.SourceLocation.IsRemote) {
// If the location is remote, do something extra
}
が trueであるSourceLocationすべての場所を必要とするコードがある場合は、このプロパティによってのコレクションをフィルタリングすることもできます。IsRemote
var remoteLocations = GetSourceLocations().Where(x => x.IsRemote);
ただし、列挙型は、アプリケーション定数として使用される場合に、1 つの点でデータ駆動型オブジェクトよりも明確な利点があります。実際、列挙型とは定数のグループです。静的な値が動的なデータ駆動型として実装されている場合、静的な値に対するルールを効果的に記述することはより困難です。
あなたの特定の例の場合、これは真実です。ルールが実際に言っているのは、「ソースの場所 == 1 の場合、これを行う」ということだけです。アプリケーションの周りにたくさんの魔法の int が浮かぶことは決してないので、上記のような列挙型を定義することは間違いありません。
これは、この場合、列挙型のみを使用し、外部データソースに値を永続化することを忘れるということですか? 必ずしもそうとは限りませんが、システムのコンテキスト内で特定の値がどのように使用されているかによってすべてが異なります。あなたの例では、これらの値は、単一のアプリケーションだけでなく、ドメイン全体で重要であるように見えます。あなたはそれらを「ビジネス価値」と説明し、レポートなどの他のアプリケーションで使用されていると述べました。私にとって、これにより、この知識を共有できる中心的な場所を提供することが完全に適切になり、列挙型で定義することに加えて、それらを保持します。
あなたは、「待って.. それは重複していませんか?それは悪いことではありませんか?」と言うかもしれません。そうですね。しかし、列挙型のみのルートを使用した場合でも、ビジネス値を本格的なドメイン オブジェクトとして設計するという設計ボーナスを得ることができます。