列挙型の定義を格納するビジネス層の別のクラスに対する一般的なコンセンサスは何ですか? これは悪い習慣ですか?これは適切な n 層設計に準拠していますか? 現時点では、私の enum 定義は、関連するクラスと見なされるさまざまなクラスに点在していますが、それらは 1 つの場所にある必要があるように感じます。実際、これは主観的な質問であり、ソリューションの残りの部分をどのように構築したかを基準にしたものですか?
3 に答える
クラスに列挙型を配置する理由がよくわかりません-おそらくファイルを意味していましたか?
個人的には、列挙型の名前を持つ列挙型ごとに個別のファイルがあります。
このファイルを列挙型が使用されている場所の近くに配置し、それに応じて名前を付けます。
列挙型を複数のアセンブリ/名前空間で共有する場合は、最も低い共有名前空間を使用するため、使用中の名前空間から見えるようになります。
列挙型を使用する場所の近くに配置すると、コードをプロジェクトに分離するのが少し簡単になります (必要な場合)。
それらすべてを 1 つのファイルにまとめることの意味がわかりません。ナビゲーションに関しては、Visual Studio には、これが不要な十分なナビゲーション機能があります。
列挙型を別のクラスに保持する
この場合、関連のない定義を 1 つのクラスに放り込んでいて、ほとんどメリットがありません。
関連するクラスのネストされた型として enum を定義する
クラス内で列挙型を保持する場合、名前付けの問題が発生する可能性があります。
class Foo
{
public enum SomeType { /* ... */ }
public SomeType SomeType { get; set; }
}
これにより、SomeType が既に定義されているというエラーが発生します。
おそらく個人的な好みに合わせて沸騰させるだけですが、ほとんどの場合、列挙型をネストせずに、それらが関連するクラスと一緒に配置します。
public enum SomeType { }
public class Foo { }
私はそれらを入れ子にしたいと何度も誘惑されました (もちろん、公開列挙型について話しているのです) が、名前付けの問題はそれだけの価値がありませんでした。たとえば、次のようになります。
class Foo
{
public enum Enumeration { }
}
Foo
次に、次のようにクラス外でそのような列挙型を使用できます: Foo.Enumeration
、しかし次の宣言(同じ名前空間内):
enum FooEnumeration { }
class Foo { }
「。」と入力する必要がないため、同様の結果が得られます。enum: を参照しているときFooEnumeration
。さらに、後者はこれを可能にします:
class Foo
{
public FooEnumeration Enumeration { get; set; }
}
これにより、前のケースで前述の名前の競合が発生します。
概要
強力な GoTo 機能を備えた IDE を使用する場合、列挙型定義の「物理的な」ローカリゼーションよりもネーミングの問題の方がはるかに重要であるように思えます。
プロジェクト内のすべての定数と列挙型に対して個別のクラスを使用したいと考えています。これにより、コードの読みやすさが向上します。ビジネス層やその他の層で参照している Comman プロジェクトがある場合は特に、これを行う必要があります。ただし、Constant/Enum クラスのためだけに不要な参照を追加する場合は、それらを同じプロジェクト内に配置する方が理にかなっています。
public class Enumerations
{
public enum Gender{
Male = 0,
Female = 1,
Unknown = 2
}
}
そして、あなたが消費するとき、あなたはそれを次のようにすることができます
GetPerson(Enumeration.Gender gender)
{
}