枚举的单独课程？

Question

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

Answer 1

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

就个人而言,每个枚举都有一个单独的文件,其中包含枚举的名称.

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

如果要在程序集/命名空间之间共享枚举,我将使用最低的共享命名空间,因此使用命名空间可以看到它.

使枚举靠近它们的使用位置将使代码分离成更容易(如果需要)的项目.

我没有看到将它们全部放在一个文件中的重点 - 导航方面,Visual Studio具有足够的导航功能,这是不需要的.

Answer 2

将枚举保持在单独的类中

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

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

当您在一个类中保存枚举时,您可能会遇到命名问题:

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时,在我看来,命名问题远比枚举定义的"物理"本地化重要得多.