2011-11-17 11 views
5

私は頻繁にこれを行うための正しい方法に疑問を抱いた。たとえばストア階層のConstデータ

、私はいくつかの計算に使用されている約100の定数(または列挙型)を持っている私のプログラムで。それらは、好ましくは1か所に貯蔵されるべきである。彼らは、例えば、階層的にグループ化することができます。コーディング中

System3/Rules/Rule7/ParameterXY/MaxAverageValue 

は当然のことながら、私はそれらの値がアクセスできるようにしたいので、ressourceのいくつかの種類に格納することは本当にオプションではありません。私の知る限り言うことができるように、これはで行うことができます

  • 非常に長い定数名
  • 名を使用して、ネストクラス
  • 名前空間

は非常に醜いです、そしてそれはです本当によく維持できない。クラスを入れ子にするのはいい方法ですが、スタイルコップ/ fxcopのいくつかの規則では禁止されているので、何らかの形で「悪い」ものでなければなりません。最後に、ネームスペースを使用して、推奨される代替案を見つけました。 Imhoでは、それぞれにほとんど何も含まれていない大量のフォルダとファイルを作成します。そして、50個のサブネームスペースがアセンブリリフレクタにポップアップすると、私は好きではありません。

あなたはどうやってこのような仕事をしていますか?何をお勧めしますか?

+1

私は名前空間を提案します。ネストクラスと長い定数名は避けてください。 –

+0

MVCはstatic const publicフィールドで生成されたクラスを使用します。IIRC – sehe

+0

@StevenMuhr:なぜネストされたクラスは読みにくいのですか?私の頭の上から、彼らは私が行くべき解決策として私を打ちました。すべての定数を1つのファイルに保存することができ、名前空間と同じ階層構造になります。 – Chris

答えて

4

非常に長い定数名

これは総の一種であるが、少なくとも、それが検出可能です。あなたのコードはすべて同じ場所にあり、問題が見つからないでしょう。私は、ネストクラスにそれを行うための良い方法を見つけることが、いくつかstylecop/FxCopのルールが自動化されたので、何らかの方法でそれがある

一つの理由は、悪いことなので、これは「悪い」でなければならない禁止

コード生成/コード検査ツールは扱いにくいです。別の理由は、Intellisenseでこれらを発見することは難しいということです。

これが悪い最も重要な理由は、レイアウトが論理的に意味をなされるために、ネストされたクラスをオブジェクト指向の依存関係に強く関連付ける必要があるためです。まれにしか起こらないケース(例:Enumerator classes)では意味がありません。あなたのクラスでは実際には何の振る舞いもオブジェクト指向も全くないので意味がありません。

あなたは説明した問題については名前空間

を、これはそれを処理するための最良の方法です。レベルごとの混乱を最小限に抑え、入力中にIntellisenseを取得して、階層を下っていくうちに絞り込んでいるものを見ることができます。

それはあなたが本当に定数の巨大なプールを必要とし、それはあなたの他の部分にそれらをバインドしても意味がありません場合は、それぞれがほとんど何も

を含まないフォルダやファイルの塊を作成し、私見アプリケーションでは、これはまれなケースの1つですが、クラスごとに1つのファイルと名前空間ごとに1つのフォルダのルールを悪用します。あなたがそれらをクラスにまったく詰め込んでいる唯一の理由は、.NETがグローバル変数をサポートしていないためです。

もう一つの提案

あなたはこれらの定数は、代わりに属しているドメイン固有のオブジェクトを持っていますか?例えば。 System3/Rules/Rule7クラスに関連するロジックはありますか?それはあなた自身のクラスで具体化すべき実際のビジネスルールのようなものではありませんか?

コードがa thicker domain modelになるように配置できる場合、定数を配置する最も論理的な場所は、対応するドメインロジックを実装するクラスです。

太いドメインを持つのが理にかなっていない場合は、完全なジェネリックルールの処理があり、ビジネスエンジンロジックを供給するために定数に依存している場合、データ駆動型アプリケーションがあります。つまり、コードではなく、設定ファイルにデータを保存する必要があります。

+0

最後の提案をありがとう、確かに行く方法があります。唯一の欠点は、特定の定数を見つけるためにコードを知らない誰かにとっては難しくなるということです。しかし、ressourceやconfigファイル(あるいは何か他のもの)とプロパティ(それらの値を得る)の代わりに、上品な解決策があります。 :) – Efrain

0

私がこれを行う方法は、Constantsという名前のファイルを封印することです。私は私のプロジェクトの残りの部分でこれを使用すると、ここで重要性が、それはあなたがそれを思い出すのに役立つし、あなたがそれを必要なときに意味をなさないだろうとして、あなたはそれに名前を付けるだろう何であるより

ので

public sealed class Constants 
{ 

    //for e.g. 
    //Sessions 
    public const string APPSESSIONKEY = "AppType"; 

} 

コードで呼び出します。

Constants.AppSessionKey 

また

その唯一の目的のプロジェクトのために一定の値を保持することであるアセンブリを作成することができます。その後、他のすべての国会はこれを参照するべきです。 DRYとKISSに続いて、参照を追加するのは簡単です。ここでの主な問題は、再コンパイルです。

1

各定数は、複数のメソッドでどのくらいの頻度で再利用されますか?あなたはあなたの定数を再構成することを検討することができます。あなたがまだ膨大な数の定数を持っている場合は、それらを読み込み専用のプロパティを持つ静的クラスに入れてみてください。

これらをすべて1か所で見るだけでよい場合は、app.configファイルに格納し、AppSettingsとConfigurationManagerクラスを使用してアクセスすることもできます。

0

リソースファイルは、値の読み取り専用文字列フィールドを持つ静的クラス階層を生成するカスタムT4テンプレートで使用します。

リソースファイルのキーは「。」で区切られています。階層を構築する。

コンパイルされたリソースファイルを1つのクラス階層にまとめることができます。

私はネストされたクラスは推奨されていませんが、私の意見では、このような状況では最も良い解決策です。