隨着我越來越多地瞭解ASP.NET MVC，我將更多地介紹給Data Annotations。
特別在MVC中，它們用於驗證，這給我一些擔憂。
最大的原因是我喜歡保持我的模型爲POCO並儘可能乾淨。
現在如果我在解決方案（即Web前端，桌面應用程序，Web服務）中跨多個項目共享這些模型類，該怎麼辦？
基本上我關注的是具體的我MVC前端應用程序可能會影響其他一些項目，如動態數據等 我已經有我的業務對象從我的數據庫模型分離（在這種情況下LINQ2SQL），所以我不擔心註解關於註釋對我的DAL有影響，但我想知道我對其他項目的恐懼是否合法。數據註釋真的是驗證的好主意嗎？
另外我認爲將一個必需的錯誤消息綁定到你的模型有點瘋狂。
我想這個問題會，如果我創建了單獨的模型爲每個項目（Web，桌面，網絡服務等）來解決，但是這將是我的實際目前的共享模式直接拷貝。 這是正確的道路嗎？
這會對我的解決方案產生重大影響（從一個模型到另一個模型的映射發生很多）。
您認爲如何？
我想聽聽你認爲數據註釋的好壞使用。
真的，真的很好的問題。尤其是因爲所有閃亮的演示示例應用程序都是圍繞DataAnnotations構建的，它處理所有的驗證，因爲它有如此不錯的閃亮賣點。無論如何，誰喜歡做驗證？
我認爲更好的方法來看待這個問題，他們應該是更全面的驗證解決方案的一部分，無論是因爲你提到的結構原因以及它們的侷限性 - 你如何驗證諸如「這個用戶名獨特？」或「這位經理是否允許將此任務分配給該員工？」使用數據註釋？
DataAnnotations不是唯一可用於驗證的方法，您可以使用多種驗證方法。我在使用DataAnnotations時看到的大多數驗證都是專門用於驗證數據庫中的數據。如MaxLength（）和Range（）。
IValidatableObject是最靈活的，當談到編寫自己的驗證，我已經看到。但是，它並沒有幫助你具有一個存放所有對象的單個存儲庫的具體示例。但沒有恐懼！
IDataErrorInfo的是另一種方式，你可以驗證數據，而這一次可以在單獨的MVC應用程序一起使用，並且不會影響其他項目。
如果一個類實現了IDataErrorInfo的接口，ASP.NET MVC框架將創建類的實例時，使用這個接口。因此，您可以使用服務定位器界面或類似的東西來分隔驗證。
但是，我發現IValidatableObject是一個更好的實現。
不知道DataAnnotations會弄亂你的其他項目，但它的預期，除非你創建了一些類，以檢查他們他們會忽略DataAnotations。
關於保持您的POCO儘可能簡單，DataAnnotations的意圖是保持元數據和數據在同一地點（即如果需要_UnitsInStock必須始終是一個正整數，不知何故這個要求與數據定義有關「庫存單位」，完全符合模型的定義）。它還有助於避免一些錯誤，因爲不管你使用驗證的地方（在mvc項目中），規則總是相同的（所以你不能忘記在檢查頁面A中的變量時檢查最小值它在頁面B）。錯誤消息不是必需的，但您可以使用它來顯示更友好的消息，並且此錯誤消息將隨處顯示。
它也很容易實現自動服務器和客戶端驗證（mvc）。
另一方面，儘管您有能力創建自定義屬性來檢查業務規則，但它需要比使用「業務類」（如果您不習慣）更多的知識和耐心，並且儘可能我知道，它只是由mvc 2正式支持。
如果您的模型類是在其他項目之間共享的，那麼您可能也有一個共享的驗證圖層，所以請使用此驗證圖層。如果你沒有它，那麼DataAnnotations會讓你的生活更輕鬆MVC項目。
我個人發現DataAnnotations非常適合驗證MVC ViewModels和發佈的輸入。我永遠不會把它們放在我的商業模式上。
我也變得相當偏袒基於屬性的驗證屬性，因爲它很容易進入反射來發現哪些屬性在哪裏。
我發現數據註釋方便了規則永遠不會根據上下文（如電子郵件地址）而變化的模型。
但是，對於更復雜的驗證（多個字段，需要DB訪問等），我使用Entity validation with visitors and extension methods中描述的訪問者模式。
我打算使用您建議的第二個選項 - 使用訪問者模式。我有一個問題，當模型被不同的上下文使用時，我們如何實現這一點。一個需要驗證字符串Customer作爲必填字段，但在另一個上下文中，不需要Customer。如何去解決這個問題。感謝你的幫助。 – 2015-10-27 21:12:25
有關訪問者模式的示例，請參閱此文章https://lostechies.com/jimmybogard/2007/10/24/entity-validation-with-visitors-and-extension-methods/然後混合諸如https：/ /www.nuget.org/packages/FluentValidation/ – 2015-10-29 19:24:01
我不認爲你需要擔心在多種技術中共享裝飾域。 DataAnnotations是BCL的一部分，你可以在WCF，WPF，MVC，Web Forms中使用它，你可以命名它（甚至可以在Silverlight中）。
由於DataAnnotations現在是BCL的核心部分，我們可以期待其他驗證框架能夠在將來讀取這些屬性，因爲Enterprise Library Validation Application Block 5.0已經做到了。這樣可以在稍後對模型進行更復雜的驗證，而無需更改核心驗證規則。
但是，我可以理解你想保持你的模型和驗證規則分開。如果這是您想要的，驗證應用程序塊（VAB）可以是一個很好的選擇（甚至可以添加，因爲它與DataAnnotations集成）。 VAB支持基於配置的驗證，它允許您將驗證規則與模型完全分開。
然而，當您的驗證規則非常簡單時，VAB可能是一種矯枉過正。這是非常強大和可擴展的，但它也是複雜和耗時的學習。
你的一個問題似乎是你想保持你的代碼清潔。 這是Asp.net MVC實現的奇妙之處。
你應該看看什麼是使用視圖模型，這有助於將您的業務邏輯從演示文稿中分離出來。
這是一個老的文章，但它解釋了基礎： http://geekswithblogs.net/michelotti/archive/2009/10/25/asp.net-mvc-view-model-patterns.aspx
我知道這是一個5歲的回答，但你可以請點我在正確的方向？你所說的話很有意義，你不能用數據註釋做所有事情。 – dpp 2016-07-26 03:13:48
@dpp - 是的，自從我構建了大量的驗證以來，已經有一段時間了，在那些年裏DataAnnotations已經有了一些改進，其他工具也有了一些改進。無論如何，我們接觸它的方式是構建一個2階段驗證管道。首先是基於DataAnnotations的方法來檢查你可以在單個對象的內存中執行的操作。第二階段是一個依賴注入的解決方案，可以與數據庫進行驗證，以查找需要查詢的唯一性和其他約束條件。今天我可能會在這裏使用FluentValidation作爲膠水。 – 2016-07-27 13:57:15