有理由不使用 CustomAttributes 吗？

Question

如果有理由我应该这样做的话，这主要是征求意见 不是 沿着这条路走。

我有一个 CodeSmith 生成的多层应用程序。在UI级别，需要有一些必填字段，并且必填字段将根据绑定实体中的字段值而变化。我正在考虑做的是将“PropertyRequired”CustomAttribute 添加到实体中的每个属性，当我在其管理器中加载实体时，我可以设置 true 或 false。然后，我将使用 Reflection 来查询属性并在 UI 级别向用户提供视觉反馈，并且在保存之前我可以验证所有必需的属性在管理器中是否具有有效值。我已经将其作为一个实体中的一个属性的概念证明，但在我尝试将其扩展到应用程序的其余部分之前，我想问是否有经验丰富的人可以告诉我去为它，或者为什么当我扩大规模时我不喜欢它。如果这是一个坏主意，或者您可以提出更好的方法，请提出您的意见。

Answer 1

这是一种非常合理的方法（我以前做过非常类似的事情）-但是有 总是 缺点：

• 任何需要实体的代码都需要额外的引用（假设属性和实体位于不同的程序集中）
• 这些值（除非你很聪明）必须在编译时确定
• 您不能在您控制之外的实体上使用它

在大多数情况下，上述情况都不是问题。如果他们 是 一个问题，您可能想要支持外部元数据模型 - 但是 除非 你需要它，这太过分了。除非必须，否则不要这样做（意思是：继续使用属性；他们是 通常 美好的）。

Answer 2

有没有固有的原因，以避免自定义属性。这是一个支持CLR的功能，这是许多可用的产品（代码契约，FxCop的，等等）的骨干。

Answer 3

这并不是一个不合理的方法，而且比将这些东西烘焙到 UI 层中更健康。在进行全面潜水之前，有几点值得考虑：

• 您将业务逻辑与业务实体本身紧密耦合。是否存在必填字段或有效值可能发生变化的情况？您可能会限制自己或面临不一致的验证机制
• 动态分配是可能的，但更棘手 - 即当您将某个字段设置为必填字段时，除非您覆盖，否则它将如此
• 如果您想要做更复杂的事情，即如果您需要将状态传递到属性驱动的验证方案中，则自定义属性可能非常不灵活。属性如声明性赋值。不过，只有 true/false 必需属性在这里不应成为问题

只是真正的魔鬼倡导者，一般来说，对于一个相当简单的应用程序，您只关心必填字段，这是一种非常简洁的方法