wpf - pattern - programming with mosh

¿Hay alguna razón para convertir los POCO en objetos de modelo?

Question

Si estoy generando objetos POCO desde EntityFramework y los uso para ir al servidor de WCF, ¿hay alguna razón para crear modelos del lado del cliente para que los Views y ViewModels los utilicen en lugar de usar los POCO directamente?

Casi todos los ejemplos de MVVM que he visto enlazan directamente con el objeto devuelto por el servicio WCF. ¿Es esta buena práctica? ¿Hay argumentos que se puedan hacer para asignar realmente el POCO a un modelo y que los View / ViewModels trabajen con el objeto Model en lugar del POCO?

La razón principal por la que podría pensar es en la validación, sin embargo, dado que los EF POCO son clases parciales, se pueden ampliar para incluir la validación.

EDITAR

La mayoría de las respuestas hasta el momento han mencionado INotifyPropertyChanged como la razón principal para construir un Modelo separado. ¿Cambia su respuesta si está utilizando entidades de seguimiento automático en lugar de POCO que ya incluyen INotifyPropertyChanged ? Las EES también son clases parciales que pueden ampliarse para incluir la validación.

Answer 1

Únase a EF POCOs si quiere hacer un CRUD simple o quiere hacer algo rápido.

De lo contrario, sus modelos del lado del servidor tenderán a estar muy estrechamente relacionados con la base de datos, que cambia muy lentamente, en comparación con la interfaz de usuario. Para una UI menos trivial, se encontrará poniendo más y más kludges solo para que su modelo de base de datos se ajuste a la UI (o lo que sea, lo que es aún peor).

Además, hay problemas de rendimiento (por ejemplo, ¿le gustaría transmitir una entidad completa cuando para la IU solo necesita un par de propiedades?), Y problemas de mantenimiento (por ejemplo, si desea validar el pedido del cliente premium de manera muy diferente a la ordinaria).

Consulte también http://ayende.com/Blog/archive/2010/08/06/data-access-is-contextual-a-generic-approach-will-fail.aspx

Answer 2

La validación es la razón principal para no unirse directamente a un POCO. Además, si el POCO aún no implementa INotifyPropertyChanged y otras interfaces requeridas, la experiencia de trabajar con el objeto en el lado WPF puede ser menos deseable, e implementar un ViewModel para envolver esto tiene sentido.

Proporcionar un ViewModel para envolver su POCO le permite encapsular la lógica en las implementaciones de ICommand , así como implementar las interfaces necesarias de manera limpia.

Answer 3

Los POCO de Rachel son solo objetos tontos generados por EF y utilizados para el transporte (DTO). Por lo tanto, no deberían tener otras cosas que saturen su dominio. Esta es una forma muy agradable de diseñar su código porque desacopla todos los requisitos del lado del cliente de aquellos en el lado del servidor. Por eso existe MVVM: para ampliar el modelo de MVC que incorpora esas preocupaciones.

No hay ninguna razón por la que no pueda vincularlos en sus vistas siempre que no los esté modificando directamente. Puedes agregarles funcionalidad agregando una clase parcial, pero ni siquiera lo haría. En ese caso, debe seguir los inquilinos de diseño de MVVM y separarlos en objetos modelo que satisfagan sus necesidades en el cliente. Esto será bastante automático una vez que conecte los eventos INotifyPropertyChanged para notificar sus vistas.

Answer 4

Mis modelos aceptan un objeto WCF que expone las propiedades que deseo usar en mi ViewModel. También puedo extender el objeto según sea necesario. Mis propiedades apuntan a la propiedad del objeto WCF y cuando tengo que enviar el objeto de nuevo al servicio WCF, no tengo que trabajar más. Los modelos heredan INotifyPropertyChanged e INotifyDataErrorInfo que los DTO (mencionados aquí como POCO) no tendrán. Su lógica de negocios / validación existe en su aplicación Silverlight y no en su Servicio WCF.

La Vista se enlaza con el Modelo de Vista que tiene un Modelo (o una colección observable de Modelos). Los modelos tienen un objeto WFCO que es un DTO (mencionado aquí como POCO). Utilizo mi ViewModel para comunicarme con el servicio, MVVM Light hace que los modelos se comuniquen con el servicio / proveedor, lo cual no me gusta.

Answer 5

Solo estoy en desacuerdo con Reed (una circunstancia inusual para estar seguro). NO implementaría un ViewModel para envolver el POCO. Implementaría una clase de Modelo para envolver el POCO y exponer los Modelos a ViewModel a través de una capa de Servicio.

El trabajo principal de ViewModel es presentar adecuadamente los datos del modelo a la vista y reaccionar a sus solicitudes. La arquitectura en la que estoy trabajando para esto se ve así:

• 1 ViewModel para cada vista
• El ViewModel llama a un objeto de capa del servicio de datos para recuperar instancias del modelo (no debe confundirse con un servicio WCF)
• La capa de servicio de datos emite las solicitudes de CRUD apropiadas para el backend (esto usa WCF, RIA o RESTful Services para Silverlight pero podría ser ADO.NET o EF directamente para WPF).
• El servicio de datos utiliza los POCO devueltos para crear objetos de modelo.
• Los objetos modelo envuelven el objeto POCO e implementan INotifyPropertyChanged. Los objetos modelo hacen cumplir las reglas de negocio.

Todavía estoy trabajando en los detalles, pero publicaré algo más concreto en un futuro próximo.