2

对于业务层中的单独类来存储枚举定义的普遍共识是什么？这是不好的做法吗？这是否符合良好的 n 层设计？目前，我的枚举定义散布在不同的、我认为是相关的类周围——但我觉得它们应该在一个地方。事实上，这是否是一个主观问题，并且与我如何构建解决方案的其余部分有关？

4

3 回答 3

9

我真的不明白为什么你会在一个类中放置一个枚举- 也许你的意思是文件？

就个人而言，我为每个枚举都有一个单独的文件，其中包含枚举的名称。

我将此文件放置在使用枚举的位置附近并相应地命名它。

如果要跨程序集/命名空间共享枚举，我将使用最低的共享命名空间，因此它对 using 命名空间可见。

将枚举靠近它们的使用位置将使将代码分离到项目中变得更容易（如果需要）。

我看不出将它们全部放在一个文件中的意义——导航方面，Visual Studio 有足够多的导航功能，这是不需要的。

于 2012-09-12T10:28:35.870 回答
6

将枚举保存在单独的类中

在这种情况下，您将不相关的定义扔到一个类中，几乎没有任何好处。

将枚举定义为与其相关的类的嵌套类型

当你在一个类中保存枚举时，你可能会遇到命名问题：

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 { }

给出类似的结果，因为您不必键入“。” 当您引用枚举时：FooEnumeration. 此外，后者允许您这样做：

class Foo
{
    public FooEnumeration Enumeration { get; set; }
}

这将在前一种情况下导致上述命名冲突。

概括

在使用具有强大 GoTo 功能的 IDE 时，在我看来，命名问题远比枚举定义的“物理”本地化重要得多。

于 2012-09-12T10:55:34.273 回答
1

我希望在我的项目中为所有常量和枚举使用单独的类。它提高了代码的可读性。你应该这样做，特别是如果你有一个在你的业务层和其他层中引用的 Comman 项目。但是，如果您只是为了一个常量/枚举类而添加不必要的引用，那么将它们放在同一个项目中会更有意义。

public class Enumerations
{
 public enum Gender{
   Male = 0,
   Female = 1,
   Unknown = 2
 }
}

当你消费时，你可以这样做

GetPerson(Enumeration.Gender gender)
{

}
于 2012-09-12T10:38:25.727 回答