我们非常喜欢EntityFramework（CTP5）并将它与ASP.NET MVC3一起使用。
我不喜欢的是; 事情在一起混合。
我可以将 DisplayAttribute ， RequiredAttribute ， RangeAttribute ， CompareAttribute 放在同一个类中，这意味着我我在数据库验证中混合，一些业务逻辑和 UI 。我甚至可以放置 ScriptIgnore 属性来将其自定义为 Json DTO 对象。所以我可以使用相同的POCO类来表示Persistance，Presentation，DTO和Business Object，以及我的domian模型。
您遵循EF POCO + MVC3工具集的哪些设计模式。你有几层？ 你在课程中添加了什么样的责任（你的POCO课程也是你的领域模型）
答案 0 :(得分：8)
我使用View Models来解决这个问题。验证和UI表示属性将转到视图模型。在此模式中，控制器使用存储库来获取EF模型，将此EF模型映射到视图模型（我为此使用AutoMapper）并将视图模型传递给视图。由于视图模型包含所有UI表示属性，因此视图的行为与预期一致。每个视图都必须有自己的视图模型。这意味着您可以拥有与同一EF模型关联的多个视图模型，但包含不同的属性子集，并根据视图的特定要求显示格式设置属性。
该过程也是相反的：控制器从视图中接收视图模型作为参数。它将视图模型映射回模型，并将EF模型传递到存储库。 UI验证属性在视图模型上处理，因为您可以在不同视图中具有不同的验证要求：例如，考虑插入/更新视图。在插入视图中，您将创建一个新实体，因此不需要Id属性。在这种情况下，您甚至不会在视图模型上具有Id属性。在更新视图中，将需要Id属性。
答案 1 :(得分：3)
我的POCO课程几乎都是领域模型，几乎从不查看模型，因此我没有这些问题。
最佳做法是在将数据从控制器传递到视图（或作为JsonResult）时使用特殊的“视图模型”类。在这种情况下，您可以在该视图模型中标记基于UI的属性。在大多数情况下（除了纯粹的crud应用程序），你需要显示比你的域对象更多或更少的东西，所以你仍然需要一些视图模型（除非你直接使用ViewData）。
域对象上的数据注释只有在您希望将它们用于业务/数据级别验证时才有意义，这些验证可以采用与UI验证不同的规则。
如果你想遵循严格的DDD，其中POCO类是域对象=提供在对象实例上执行域逻辑的方法，你应该更进一步，因为在这种情况下你的业务facede不应该将域对象暴露给控制器。在这种情况下，您将最终获得在业务外观上公开并在控制器中使用的数据传输对象。我不是纯粹的，所以在这种情况下，我很想直接在DTO上使用数据注释，但这取决于其他要求。