2010-11-10 22 views
6

He jugado con algunas implementaciones diferentes de Model-View-ViewModel y encuentro constantemente una situación en la que no estoy seguro de la forma correcta de proceder. Sé que uno de los objetivos de MVVM es desacoplar la vista de la lógica de la aplicación para que la lógica se pueda probar sin la presencia de una vista. Poner la lógica en un ViewModel que no tiene dependencias en la View resuelve este problema. Estupendo. Aún mejor si el Modelo se puede desacoplar del ViewModel de tal manera que se pueda burlar.EF4 + MVVM - ¿Exponer entidades en ViewModel?

Así que mi pregunta es, ¿debería el ViewModel desacoplar el Modelo de la Vista? En otras palabras, ¿está "bien" exponer entidades EntityFramework a la Vista a través del ViewModel? Por ejemplo, supongamos que hay un cuadro combinado en la vista donde el usuario puede elegir un estado para una dirección. En el modelo AddressView, ¿el estado debería estar expuesto como una propiedad de tipo entidad real, o debería estar expuesto como un modelo StateViewModel? Si debe ser una propiedad de tipo StateviewModel-typed, no entiendo cómo debe gestionarse el modelo subyacente dentro del setter AddressViewModel.State (porque lo que se establece en la propiedad es un StateViewModel y no una entidad State).

Me parece que esto podría ir de cualquier manera, pero parece más coherente que nunca exponer el modelo directamente a la vista. ¿Pensamientos?

Respuesta

2

El objetivo del modelo de vista es desacoplar la vista del modelo de datos. Si no hay funcionalidad en la vista que esté acoplada al modelo de datos, no es necesario ningún modelo de vista.

Si tiene un objeto en el modelo de datos cuyas propiedades no cambian después de haber sido creado, y que la vista no se va a modificar, y que se puede presentar en la interfaz de usuario sin formatear o convertir, entonces está no acoplando ninguna de sus funciones a la vista al exponerlo directamente. No necesita un modelo de vista para esto.

En su ejemplo, probablemente pueda salir sin crear una clase StateViewModel, ya que una clase así no haría nada realmente.

+0

Eso es cierto en teoría, pero en la práctica a veces las cosas no son tan constantes como a las personas (los desarrolladores entre ellos) les gustaría pensar, por ejemplo, la lista de estados podría expandirse en el futuro para incluir otros países, etc. .. –

+1

Ese no es el tipo de cambio que tendría un impacto en esta decisión. Agregar nuevos estados a la lista no crea el requisito de que sus propiedades sean editables en la interfaz de usuario. –

4

Debe esforzarse por desacoplar por completo su modelo de su vista, este debería ser un objetivo, podría cumplirlo, o no, pero aún así debería ser su objetivo.

Específicamente su pregunta se refiere a una lista de constantes (más o menos), que es un caso fácil. Corrígeme si me equivoco aquí, pero probablemente tengas una tabla States con un code y un name para cada estado, y luego tienes otra tabla con una clave externa para el primero.

En este escenario es mejor para cargar y crear la lista StateViewModel una vez durante la inicialización de la aplicación, y luego tratar con el valor de clave externa (el estado code por así decirlo) en toda la aplicación en lugar de la StateViewModel los propios objetos. Las propiedades que debe utilizar son los SelectedValue y SelectedValuePath del ComboBox, ejemplo:

<ComboBox ItemsSource="{x:Static StateViewModel.StaticList}" 
      SelectedValue="{Binding StateForeignKey}" 
      SelectedValuePath="code" 
      DisplayMemberPath="name" /> 

Esto llenará los ComboBox con StateViewModel objetos (que fueron creados usando un contexto ahora dispuesta), pero pasarán de code el elemento seleccionado propiedad en el campo encuadernado StateForeignKey; adicionalmente, el ComboBox mostrará la propiedad name para que sea legible por el ser humano.

0

La razón por la que no se puede exponer a la entidad en modelo de vista se debe a usted no debe contaminar la Entidad con vista al código específico como IDataErrorInfo, INotifyPropertyChanged, etc. IEditableObject

Entidad es núcleo de la aplicación y debe ser POCO, puede ser reutilizado en todo tipo de aplicación. Por ejemplo, si desarrolla una aplicación accesible a través de Mobile, Web y Desktop, no necesita crear Entity para cada tipo de aplicación.

motivo de desacople? lo siento, pero no estoy de acuerdo, porque no veo ningún beneficio al desvincular Model y ViewModel porque la prueba unitaria funcionará bien con o sin Entity dentro de ViewModel.

ACTUALIZACIÓN

triste olvidé que utilizó EF4. La entidad EF4 es compatible con INotifyPropertyChanged por defecto, por lo que será aceptable exponer su entidad en ViewModel.

1

Enlazo la entidad directamente a mi vista a través del modelo de vista a menos que tenga que agregar propiedades específicas como IsSelected etc ... para treeviews. Si tengo que agregar propiedades de adición, entonces tengo el modelo de vista ajustado a cada propiedad de la entidad.

Cuestiones relacionadas