是否有原因不使用CustomAttributes？

這主要是一個請求評論，如果有一個原因，我應該不是走這條路。是否有原因不使用CustomAttributes？

我有一個多層CodeSmith生成的應用程序。在UI級別，需要一些必需的字段，並且所需字段將根據綁定實體中的字段值而變化。我想要做的是在實體中的每個屬性中添加一個「PropertyRequired」CustomAttribute，當我在其管理器中加載實體時，我可以設置true或false。然後我將使用Reflection來查詢屬性並在UI級別向用戶提供可視反饋，並且在保存之前我可以驗證所有必需的屬性在管理器中具有有效值。我已經將此作爲一個實體中的一個屬性的概念驗證，但在我嘗試將其擴展到應用程序的其餘部分之前，我想問問是否有更多經驗的人告訴我要去爲什麼呢，或者爲什麼我放大時我不會喜歡它。如果這是一個壞主意，或者如果你可以建議更好的方法，請提供你的意見。

來源

2009-10-06 jac

它是做一個非常合理的方式（我以前做的非常類似的東西） - 但也有總是缺點：

任何代碼需要的實體將需要額外的參考（假設該屬性和實體在不同的組件）
值（除非你很聰明吧）必須在編譯時決定
你不能在實體上使用您的控制之外

在大多數情況下，以上都不是問題。如果他們是的問題，您可能需要支持外部元數據模型 - 但除非您需要它，這將是矯枉過正。不要這樣做，除非你必須（意思是：繼續前進，使用屬性;他們通常罰款）。

來源

2009-10-06 21:07:01

避免自定義屬性沒有內在原因。它是支持的CLR功能，它是許多可用產品（代碼合同，FxCop等）的支柱。

來源

2009-10-06 21:07:04 JaredPar

這不是一種不合理的方法，並且比烘焙這些東西進入UI層更健康。在進行全面潛水之前，有幾點需要考慮：

您將業務邏輯與業務實體本身緊密耦合。是否有必要或有效值可能更改的字段？您可能會限制自己或面臨不一致的驗證機制
動態分配是可能的，但更棘手的 - 當你設置爲需要現場多數民衆贊成它是什麼，除非你重寫
自定義屬性可以說是相當不靈活，即如果您想要做更復雜的事情 - 即如果您需要將狀態傳遞給屬性驅動的驗證方案。屬性如聲明性分配。只有具有真/假所需的屬性不應該是一個問題，這裏雖然

只是作爲一個鬼子倡導真，一般爲一個相當簡單的應用程序，你只關心必填字段，這是一個相當整齊的方式做它

來源

2009-10-06 22:00:33 dbez

是否有原因不使用CustomAttributes？

回答

相關問題