Question

我已经将Enum定义为ASP.NET MVC应用程序的模型对象的一部分。

Enum被称为'ContentTypes'，看起来像这样：

public enum ContentTypes
{
    [Description("News story")]
    NewsStory = 1,

    [Description("Article")]
    Article = 2
}

现在我打算在名为“Route”的枚举项中添加另一组属性。该属性允许我将每个ContentType映射到可以处理它的URL。

所以在此之后我会：

public enum ContentTypes
{
    [Description("News story")]
    [Route("news/item/{URLName}")]
    NewsStory = 1,

    [Description("Article")]
    [Route("article/item/{URLName}")]
    Article = 2
}

你认为恩赐此时的重量太重了吗？

将枚举项分解为类，然后为每个类提供“描述”和“路径”属性会更好吗？

Answer 1

您确实尝试使用Enum来区分Content对象的多个变体，而不会遇到实际创建Content对象的多个版本的麻烦。

可以肯定的是，应用程序的行为将取决于枚举设置的内容。例如，您可能会有：

public Content
{
    private ContentTypes contentType;
    public string ToString()
    {
        switch (contentType)
        ...
    }
}

从可维护性的角度来看，这会让你发疯。请考虑使用继承来获取您所追求的行为：

public Content
{
    public abstract string ToString();
}

public NewsStory : Content
{
    public override string ToString() { /* Appropriate formatting of output */ }
}

public Article : Content
{
    public override string ToString() { /* Appropriate formatting of output */ }
}

现在要真正获得幻想（并使用“按合同设计”方法），考虑任何内容可能具有的所有共同点并定义一个接口，例如： IContent。如果你这样做，你可以做以下事情：

List<IContent> myContent;
foreach (IContent ic in myContent) ic.ToString();

Answer 2

就个人而言，我认为Enums应该保持简单。在不仅仅是助记符的地方，我会考虑福勒的“用状态/策略模式替换类型代码”。

所以，是的，我会转换为一个类。

Answer 3

您可以合并属性，使其看起来更像这样：

[Description("x"), Route("y")]

如果您认为语法看起来更好。但我同意Mitch的观点，那些可能会更好的作为课程，特别是如果你有可能在将来添加另一个属性。

是否存在Enum可能变得过于膨胀的程度？

3 个答案: