C# 规避自定义属性参数的常量要求

我正在寻找在创建自定义属性时绕过属性参数限制的方法。具体来说，我有一个自定义的DisplayName属性，它从数据库中检索数据，然后确定在视图的LabelFor帮助器中显示什么。这是一个更大的原型的一部分，所以代码优化现在是次要的关注点。当我们准备开始开发实际项目时，我们将实现缓存和其他性能改进。我可以为我的实际问题提供一些背景，但我希望答案足够笼统，可以应用于需要这样做的任何类型的属性

构造函数除了为某些私有属性指定参数外，不做任何工作：

public DisplayNameTranslationAttribute(string pageName = "", [CallerMemberName] string fieldName = "")
{
    _pageName = pageName;
    _fieldName = fieldName;
}

所有重载都发生在DisplayName覆盖方法中。原因是每次加载页面时都会调用DisplayName，而构造函数在第一次加载页面时只调用一次，以后再也不会调用

public override string DisplayName
{
    get
    {
        string displayName = string.Empty;

        _customerID = 1; //This needs be accessed or retrieved somehow, from somewhere

        using (var db = new SomeDataEntities())
        {
            SomeData sd =
            db.SomeDatas.FirstOrDefault(t => t.PageName == _pageName && t.FieldName == _fieldName);

            SomeOtherData od = null;

            if (sd != null)
            {
                od = sd.SomeOtherDatas.FirstOrDefault(c => c.CustomerID == _customerID);
                displayName = Equals(od, null) ? sd.ColumnN : od.ColumnZ;
            }
        }

        return displayName.IsNullOrWhiteSpace() ? _displayName : displayName;
    }
}

---

如您所见，我现在正在将customerID硬编码为1。我需要能够向客户ID提供实际值。我知道我不能将它作为参数直接传递给属性，所以我需要做的是发现绕过此限制的方法。是否有任何选项可以欺骗属性，或者更可能的是，从内存中的其他地方检索ID？

我无法想象显示属性会被这样使用。请停止那样做

如果标签名取自DB，则它可能是领域知识的一部分，不应被视为视图逻辑（即

DisplayName

属性）

不必进行这些攻击，只需通过从控制器传递到视图的ViewModel获取这些信息即可。控制器将从数据库中获取数据。简单

// pseudo-code
public ActionResult Indes(int customerId)
{
    var viewModel = new ViewModel();
    viewModel.Value = dbContext.Customers.FirstOrDefault(c => c.CustomerId == customerId);
    viewModel.DisplayName = dbContext.FieldNames.FirstOrDefault(f => f.Name == some condition);

    return View(viewModel);
}

编辑：再想一想，您可以尝试创建自己的属性，完全独立于显示属性，将应该放置的字段放置在那里。然后实现它，为标签提供正确的字段名

---

见示例。这是不知羞耻地从我这里偷来的。此实现不满足您的需要，但显示了一个示例。

这是我的备份计划。不幸的是，这将应用于即将到来的项目中的几乎每一个ViewModel，我们需要构建的页面数量并非微不足道。这将使我们构建的每个ViewModel的大小增加一倍。这使得实现和维护变得更加麻烦，我希望通过编写属性和装饰一切来避免这一麻烦。但是，如果最终的答案真的是“这是一个糟糕的主意！”我不会反对它。是的，这是一个糟糕的主意！不幸的是，没有简单的方法来完成任务。要么是难以维护的黑客负载，要么是额外的属性负载。我可以想出一种在视图模型中实现一些接口的方法，并且有一个过滤器，可以检测接口/属性并将值填充到模型中。但是属性本身不能这样做。你有特定帖子的链接吗？在网站上搜索或者通过谷歌上的网站搜索对我来说没有任何帮助。我可能找错东西了你是说Jimmy的帖子？没有关于这个话题的帖子。模型Metada提供者取自他的书，但它不做您想做的事情，因此需要自己实现反射/属性检测