实体框架 POCO +推荐图案
我们非常喜欢 EntityFramework (CTP5)，并将其与 ASP.NET MVC3 一起使用。
我不喜欢的是； 事物混合在一起。
我可以将 DisplayAttribute、RequiredAttribute、RangeAttribute、CompareAttribute 放在同一个类中，这意味着我混合在数据库验证、一些业务逻辑和UI。我什至可以放置 ScriptIgnore 属性将其自定义为 Json DTO 对象。因此，我可以将相同的 POCO 类用于持久性、演示、DTO 和业务对象，并作为我的领域模型。
您使用 EF POCO + MVC3 工具集遵循哪些设计模式。你有哪几层？ 您向您的类添加了哪些职责（您的 POCO 类也是您的领域模型吗）
We do like EntityFramework (CTP5) quite a lot and Using it along with ASP.NET MVC3.
What I dislike is;
things are mixed in together.
I can place a DisplayAttribute, RequiredAttribute, RangeAttribute, CompareAttribute together in the same class which means I am mixin in database validation, some business logic and UI alltogether. I can even place ScriptIgnore attribute to customize it as a Json DTO object. So I can use the same POCO class for Persistance, Presentation, DTO and Business Object, and as my domian model.
Which design patterns do you follow along with EF POCO + MVC3 toolset. What layers do you have?
What resposibilities do you add to your classes (Is Your POCO class also your Domain Model)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我使用视图模型来解决这个问题。验证和 UI 表示属性转到视图模型。在此模式中，控制器使用存储库来获取 EF 模型，将此 EF 模型映射到视图模型（我使用 AutoMapper ）并将视图模型传递给视图。由于视图模型包含所有 UI 表示属性，因此视图的行为符合预期。每个视图必须有自己的视图模型。这意味着您可以将多个视图模型关联到同一 EF 模型，但包含不同的属性子集，并根据视图的特定要求显示格式属性。
该过程也以相反的方式工作：控制器从视图接收视图模型作为参数。它将视图模型映射回模型，并将 EF 模型传递到存储库。 UI 验证属性在视图模型上处理，因为不同视图中可能有不同的验证要求：例如插入/更新视图。在插入视图中，您将创建一个新实体，因此不需要 Id 属性。在这种情况下，您的视图模型上甚至没有 Id 属性。相反，在更新视图中，需要 Id 属性。
I use View Models to solve this problem. Validation and UI presentation attributes go to the view model. In this pattern the controller uses a repository to fetch an EF model, maps this EF model to a view model (I use AutoMapper for this) and passes the view model to the view. Because the view model contains all the UI presentation attributes the view behaves as expected. Each view must have its own view model. This means that you could have multiple view models associated to the same EF model but contain a different subset of properties and display formatting attributes based on the specific requirements of the view.
The process works the other way around as well: the controller receives a view model from the view as argument. It maps the view model back to a model and passes the EF model to the repository. UI validation attributes are handled on the view model because you could have different validation requirements in different views: think for example Insert/Update views. In the insert view you will be creating a new entity thus the Id property won't be required. You won't even have an Id property on your view model in this case. In the update view on the contrary the Id property will be required.
我的 POCO 类几乎总是域模型，几乎从不查看模型，所以我没有这些问题。
最佳实践是在将数据从控制器传递到视图（或作为 JsonResult）时使用特殊的“视图模型”类。在这种情况下，您可以在该视图模型中标记基于 UI 的属性。在大多数情况下（纯增删改查应用程序除外），您需要显示比域对象更多或更少的内容，因此您仍然需要一些视图模型（除非直接使用 ViewData）。
仅当您想将域对象上的数据注释用于业务/数据级别验证（可以采用与 UI 验证不同的规则）时，域对象上的数据注释才有意义。
如果您想遵循严格的 DDD，其中 POCO 类是域对象 = 提供对对象实例执行域逻辑的方法，您应该走得更远，因为在这种情况下，您的业务面不应将域对象暴露给控制器。在这种情况下，您最终将得到在业务外观上公开并在控制器中使用的数据传输对象。我不是纯粹主义者，所以在这种情况下，我愿意直接在 DTO 上使用数据注释，但这取决于另一个要求。
My POCO classes are almost always domain models and almost never view models so I don't have these problems.
The best practice is to use special "view model" class when passing data from controller to view (or as JsonResult). In such case you mark UI based attributes in that view model. In most cases (except pure crud applications) you need to display something more or something less then your domain object so you still need some view model (unless you use ViewData directly).
Data annotations on domain object makes sense only if you want to use them for business/data level validation which can take different rules then UI validation.
If you want to follow strict DDD where POCO classes are domain objects = offers methods performing domain logic on instance of object you should go even further because in such case your business facede should not expose domain objects to controller. In such case you will end up with data transfer objects exposed on business facade and consumed in controller. I'm not purist so in this scenario I'm open minded to using data annotations on DTOs directly but it depends on another requirements.