C# 最佳实践：将ID转换为专有名称

我今天在工作的时候正在做一个MVC项目，我遇到了一个问题，我真的无法找出最佳实践

假设我有一个用户，每个用户都有一个用户类型ID或代码（不一定位于另一个表中）。在这种情况下，UserType不在另一个表中，而是硬编码的。但是在将来，应该从持久层加载。
ID 1是管理员
ID 2是版主
ID3是一个普通用户

现在我有了这个用户的普通索引、创建、编辑视图，UserType Id是UserType的下拉列表

到目前为止，代码在控制器中构建了SelectList，并且在那里它都是硬编码的

在索引页面上，我希望显示用户类型“name”，而不是表示该名称的id

最后，我在控制器中保留了硬编码的值，在UserViewModel中，我添加了一个“UserTypeStr”属性，这将为该用户类型提供一个名称

像这样：

public class User
{
    public int UserType{get;set;}
    // other fields...

    public string UserTypeStr
    {
        get
        {
            switch(UserType)
            {
                case 1: return "Admin";
                case 2: return "Moderator";
                // ... and so on
            }
        }
    }
}

现在这段代码的伸缩性不是很好，现在我有了重复的代码，这在某种程度上做了相同的事情

我不完全确定，解决这个问题的最佳方法是什么。我有一些想法，我可以把它们放在一个类中，或者是一个专用的ViewModel类，或者是一个工厂，或者是类似的，但我觉得这并不正确

我期待着看到你们是如何解决这个问题的

顺便说一句，我知道这不是一个很好的设计，但我的时间有限，所以我没有重构太多的代码

我应该注意

---

代码必须进行缩放，以便以后可以将其添加到数据库中并进行翻译。

创建

enum

配额：

public enum UserType {
    NotSet = 0,
    Admin,
    Moderator
}

public class User
{
    public UserType Type {get; set; }

    public string TypeOfUser() {
        return Type.ToString();
    }
}

---

这种方法可以扩展，并且是常见的做法（将枚举映射到数据库枚举）。如果进行了更改，它确实需要重新编译，但我不会将其标记为“不可缩放”…

您可以创建一个

字典，保存UserTypeId和UserTypeValue的列表，并将此列表放在一个公共位置

然后，您可以根据用户类型或用户与列表之间的内部联接（使用LINQ）在列表上进行查找。
您可以使用带有
Description
属性的枚举

private enum UserTypeEnum
{
    [Description("Administrator")]
    Admin,
    [Description("Moderator")]
    Mod
};

public UserTypeEnum UserType;
public string UserTypeStr { get {return UserType.ToString();} }

…并使用转换为字符串…并使用枚举为视图中的下拉列表构建
SelectList
。完全不可缩放。所以这并不能解决问题。@AndréSnedeHansen它在什么意义上不可伸缩？i18n，将来应该可以将其改变为灵活的。也就是说，将来它将从数据库或其他存储库中加载。这与我的想法非常接近，创建一个包含此类信息的类，并且如果将来需要的话，可以从其他地方获取词典。其他人刚刚因为同样的答案而被否决（这是有充分理由的）。它无法缩放。每次需要添加新代码时，都必须重新编译，如果使用该代码，则使用该代码的结构可能会中断。它不能为将来扩展，因为将来可能需要添加新的用户类型，或者通过数据库使其变得灵活。@AndréSnedeHansen“每次要添加新的用户类型时都必须重新编译”你会随心所欲地添加新的用户类型吗？！真正地当然，我的回答也是如此。只是没有达到你期望的水平。我删除它是因为我不想和你一起进入兔子洞。@AndréSnedeHansen哦，我明白了，所以你不是在寻求一种直接将ID转换为名称的方法，而是更高层次的管理数据来源的方法。您可以使用类似于“存储库模式”的东西—这样您的显示逻辑就不会关心数据来自何处—在硬编码时，您只需要重新编译enum实现，而无需其他任何操作，当准备移动到数据库时，您不需要重新编译任何内容，只需切换存储库提供程序。（杂项说明，出于某种原因，Xander的答案没有出现在我面前，我的答案几乎是一个骗局）@turch我只是在考虑了删除的“可伸缩性”后才解开了它。出于伸缩的目的，字典中的做法比这更好。但是存储库模式是解决这个问题的一个好方法，但是对于这样一个小问题，它似乎设计得太过了。把它放在数据库中有什么错呢？绝对没有什么错？是我让它看起来如此，因为那不是我的本意！在未来，它应该在数据库中，但现在它不是，因为我在这个项目上的时间限制，不允许我改变太多。顺便说一句，请阅读最后一行。恐怕我不理解您的问题-只需在数据库中创建一个名为
UserTypes
或类似的表，并使用您最喜欢的ORM查询…？问题是，我想知道做这件事的最佳做法是什么？与MVC配对。应具有可扩展性，并支持DI和IoC。我在寻找解决这个问题的最佳实践。如果你认为它将来会出现在数据库中。只要在.net中假装它已经是了。但是，不要从数据库加载列表，而是在代码的中心位置加载。