我们非常喜欢 EntityFramework (CTP5) 并将其与 ASP.NET MVC3 一起使用。
我不喜欢的是； 东西混在一起了。
我可以将 DisplayAttribute、RequiredAttribute、RangeAttribute、CompareAttribute 放在同一个类中，这意味着我我在 数据库验证、一些 业务逻辑 和 UI 中混合在一起。我什至可以放置 ScriptIgnore 属性将其自定义为 Json DTO 对象。所以我可以将相同的 POCO 类用于 Persistance、Presentation、DTO 和 Business Object，并作为我的 domian 模型。
您在使用 EF POCO + MVC3 工具集时遵循哪些设计模式。你有几层？ 你为你的类添加了哪些职责（你的 POCO 类也是你的领域模型吗）
【问题讨论】：
标签： asp.net-mvc entity-framework design-patterns poco
我的 POCO 类几乎总是领域模型，几乎从不查看模型，所以我没有这些问题。
最佳实践是在将数据从控制器传递到视图（或作为 JsonResult）时使用特殊的“视图模型”类。在这种情况下，您在该视图模型中标记基于 UI 的属性。在大多数情况下（纯粹的 crud 应用程序除外），您需要显示更多或更少的内容，因此您仍然需要一些视图模型（除非您直接使用 ViewData）。
只有当您想将它们用于业务/数据级别验证时，域对象上的数据注释才有意义，该验证可以采用与 UI 验证不同的规则。
如果您想遵循严格的 DDD，其中 POCO 类是域对象 = 提供在对象实例上执行域逻辑的方法，您应该走得更远，因为在这种情况下，您的业务面不应该将域对象暴露给控制器。在这种情况下，您最终将获得在业务外观上公开并在控制器中使用的数据传输对象。我不是纯粹主义者，所以在这种情况下，我愿意直接在 DTO 上使用数据注释，但这取决于其他要求。
【讨论】：
我使用视图模型来解决这个问题。验证和 UI 表示属性转到视图模型。在此模式中，控制器使用存储库来获取 EF 模型，将此 EF 模型映射到视图模型（为此我使用 AutoMapper）并将视图模型传递给视图。因为视图模型包含所有 UI 表示属性，所以视图的行为符合预期。每个视图都必须有自己的视图模型。这意味着您可以将多个视图模型关联到同一个 EF 模型，但包含不同的属性子集，并根据视图的特定要求显示格式属性。
这个过程也以相反的方式工作：控制器从视图接收视图模型作为参数。它将视图模型映射回模型并将 EF 模型传递到存储库。 UI 验证属性在视图模型上处理，因为您可能在不同的视图中有不同的验证要求：例如插入/更新视图。在插入视图中，您将创建一个新实体，因此不需要 Id 属性。在这种情况下，您的视图模型上甚至都没有 Id 属性。相反，在更新视图中，将需要 Id 属性。
【讨论】：