对云中的asp.net MVC应用程序使用枚举或数据库查找表或两者的最佳实践/设计决策是什么？


What is the best practice/design decision to use enums or database lookup tables or both for an asp.net MVC app in the cloud

我正在编写一个ASP.NET MVC应用程序，但我不确定设计决策。我不确定最佳设计是使用枚举值还是将这些值存储为数据库中的查找表。我可以想象，对于一个Windows应用程序，所有这些查询都不是问题，但是对于一个在云计算中运行的、使用关系数据库的高流量Web应用程序，查找表是可以的，我不太确定。

该应用程序需要可维护，将来需要支持多语言。其他开发人员将不得不在系统上工作，所以我需要设计正确且易于维护。

我目前使用的枚举值如下通知方法(无、电子邮件、短信)性别(男、女)订单状态(打开、关闭、正在进行、交货进度支付服务(现金，银行转账，贝宝，GoogleWallet)

Enums适合我，因为代码中有链接到Enum的业务规则，使用Enums值而不是字符串的业务规则会使应用程序更易于阅读，也不容易出错。

但是，上述情况不适用于以下情况。我的网络前端有一个选择/下拉控件。要填充下拉列表，我有以下代码

1
2
3
4
5
6
7
8
  var paymentServices=
          Enum.GetValues(typeof(PaymentService))
          .Cast<PaymentService >()
          .Select(d => new SelectListItem()
          {
              Text = d.ToString(),
              Value = ((int)d).ToString()
          }).ToList();

我希望显示电子邮件，而不是枚举值e mail，我希望单词之间有空格。

所以我最终使用属性，并在EnumHelper类中使用静态方法来读取这里描述的属性

我的order和preference db表每个表大约有20个枚举。

对于我的情况，最好的做法是

  • 仅对显示值(如friendlynames、description和tooltip)使用带有枚举属性的c枚举。

  • 只需使用数据库查找表。缺点是业务规则必须基于查找表中所选值的字符串值。要转到我的首选项或顺序编辑屏幕，我必须在数据库中分别读取20个查找表，以便呈现下拉控件。这使得编写代码和报告更加容易，但系统将承受沉重的负载(系统拥有数千个用户)

  • 为业务规则提供简单的枚举值，并使用匹配的查找数据库表，并在这些表中存储要在前端UI上显示的其他显示列。缺点是我必须保持基本枚举编号与数据库查找表同步。

    • 我如何决定最佳设计决策，还是有更好的解决方案？

    Have simple enums values for business rules and use matching lookup
    database tables and store in those tables the additional display
    columns to show on the frontend UI. The disadvantage is I have to keep
    the basic enum numbering in sync with the database lookup tables.

    您可以研究t4模板，这意味着应用程序中的枚举是半自动从数据库中的查找表生成的。(您可以从"构建"菜单中选择一个选项来重新创建所有项目。)我们目前在工作中的一个大型项目上执行此操作，它工作得很好。

    当然，这样做的好处是，您不必在应用程序中使用幻数，也不必手动保持同步。外键和强类型代码，双赢。

    这似乎相关：SQL表和C枚举

    为了在此基础上进行扩展，我们还使用反射来获取枚举的DisplayValue属性。然而，仅仅因为我们这样做并不能使它成为最佳实践。我们在客户机上运行，而不是在云中运行，因此反射并不是一个大问题。我不知道当一台机器向多个用户发送页面时，这种反射会有多大。也就是说，微软在使用HTML助手时充分利用了反射，反射速度可能比访问数据库快20倍。但我离题了…

    相关讨论

    如果您的枚举值需要本地化，为什么不积极主动地使用它，并立即使用.resx文件作为英文标题呢？使用属性意味着您要静态地声明每个枚举值的描述应该是什么，这本质上与可本地化相反。

    考虑到using resx = namespace.resxFile(我建议使用一个.resx文件，专门保存枚举值的标题，即将其他UI资源放在另一个文件中)，每个枚举值都存储为一个按照惯例[enumValue]Caption命名的字符串，您的paymentServices列表可以如下所示：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    var paymentServices =
        Enum.GetValues(typeof(PaymentService))
            .Cast<PaymentService>()
            .Select(d => new SelectListItem()
            {
                Text = resx.ResourceManager
                           .GetString(string.Format("{0}Caption", d.ToString())),
                Value = ((int)d).ToString()
            }).ToList();

    当需要本地化时，您只需翻译.resx文件并将资源的区域性设置为所需的区域性。

    缺点很明显是，您不能拥有这样的功能，例如，允许用户编辑翻译并添加新的支持语言，因为.resx文件内置于您的应用程序中；这也意味着只要需要新的枚举值，代码就需要更改。

    好处是您没有访问数据库，并且您的代码是独立的，这意味着未来的开发人员不需要在代码库之外的任何地方查找任何东西。

    最好的归根结底就是你的需求和要求。