1

如果有理由我不应该走这条路，这主要是征求意见。

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

4

3 回答 3

3

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

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

在大多数情况下，以上都不是问题。如果它们是一个问题，您可能希望支持外部元数据模型 - 但除非您需要它，否则这将是矫枉过正。除非必须，否则不要这样做（意思是：继续使用属性；它们通常很好）。

于 2009-10-06T21:07:01.333 回答
1

没有内在的理由来避免自定义属性。它是受支持的 CLR 功能，是许多可用产品（代码合同、FxCop 等）的支柱。

于 2009-10-06T21:07:04.657 回答
0

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

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

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

于 2009-10-06T22:00:33.527 回答