Enlace EF4 con Caliburn.Micro: ¿Debo exponer mi Entidad como una propiedad de ViewModel?

Question

Con Caliburn.Micro Me gustaría saber los pros y los contras de exponer una Entidad EF4 como una propiedad de ViewModel (una técnica discutida hereand here). Esto me permite evitar escribir getters y setters para cada campo (ver OneCustomer a continuación). El inconveniente es que necesito escribir todas las declaraciones vinculantes en XAML (debajo de LastName no está en ViewModel, pero sí requiere el enlace XAML). Si sigo la técnica prescrita de llenar mi ViewModel con propiedades para cada campo (como FirstName a continuación), en última instancia tendré que escribir una tonelada de código adicional para que se llame a NotifyOfProperyChange. La aplicación será bastante grande. ¿Debo exponer cada entidad como una propiedad de ViewModel?

En mi modelo de vista:

private MyEntities _context = new MyEntities(); 
private BindableCollection<Customer> _custBindableCollection; 
private Customer _oneCustomer; 
private string _firstName; 

public void Load() 
{ 
    _custBindableCollection = new BindableCollection<Customer>(_context.Customers.Where(row => row.CustomerType == "FOO")); 
    AllCustomers = _custBindableCollection; 
    _oneCustomer = _custBindableCollection.FirstOrDefault(); 
    FirstName = _oneCustomer.FirstName; 
    OneCustomer = _oneCustomer; 
} 

public BindableCollection<Customer> AllCustomers 
{ 
get { return _custBindableCollection;} 
set {_custBindableCollection = value; 
     NotifyOfPropertyChange(() => AllCustomers);} 
} 

public Customer OneCustomer 
{ 
get { return _oneCustomer;} 
set { _oneCustomer = value; 
     NotifyOfPropertyChange(() => OneCustomer);} 
} 

public string FirstName 
{ 
    get { return _firstName; } 
    set { 
     _firstName = value; 
     _oneCustomer.FirstName = value; 
     NotifyOfPropertyChange(() => FirstName); 
     NotifyOfPropertyChange(() => CanSaveChanges); 
    } 
} 

public void SaveChanges() 
{ _context.SaveChanges(); } 

public bool CanSaveChanges { get { return IsValid; } } 

en mi opinión:

<StackPanel> 
<StackPanel Orientation="Horizontal"> 
    <Label Content="First Name:" /> 
    <TextBox x:Name="FirstName" /> 
</StackPanel> 
<StackPanel Orientation="Horizontal" DataContext="{Binding Path=OneCustomer}"> 
    <Label Content="Last Name:" /> 
    <TextBox x:Name="LastName" Text="{Binding LastName}" /> 
</StackPanel> 
<Button Content="Load Data" x:Name="Load" /> 
<Button Content="Save" x:Name="SaveChanges" /> 
<DataGrid x:Name="AllCustomers" /> 

Gracias de antemano.

Answer 1

Con Caliburn.Micro Me gustaría saber los pros y los contras de exponer un EF4 Entidad como una propiedad del modelo de vista (una técnica discutido aquí y aquí).

No estoy seguro de los pros/contras, pero puedo decir que se utilizan ambos métodos. Por ejemplo, tome una pantalla de inicio de sesión simple, generalmente pongo el nombre de usuario como una propiedad en ViewModel, pero en los casos en que el formulario es más complejo, ViewModel puede agregar otros modelos de visualización (modelos de visualización) para lograr lo mismo. CM no afecta los pros/contras, ya que es más una cuestión de Con MVVM, cuáles son los pros/contras. CM te ayudará a vincular ambas cosas.

• Si usted tiene una propiedad en el modelo de vista llama CustomerName, simplemente nombrar un cuadro de texto X: name = "CustomerName".
• Si tiene una propiedad en el ViewModel que es una instancia de una clase llamada Customer, nombre TextBox x: name = "Customer_Name" y nuevamente, CM manejará los enlaces.

Así que desde su xaml arriba:

<TextBox x:Name="LastName" Text="{Binding LastName}" /> 

que no es necesario para establecer el DataContext en el StackPanel.En su lugar:

<TextBox x:Name="OneCustomer_LastName"/> 

Una cosa que puede hacer que la unión a DataForms y DataGrids más fácil está siguiendo un método en el que crear modelos de pantalla para el modo en que se representan los datos en la pantalla.

Esta es mi opinión, pero personalmente nunca vincularé directamente a una entidad EF/Linq. En su lugar, crearé un modelo de visualización para representar esa entidad y cómo quiero que se muestre y usar AutoMapper para realizar las asignaciones. En muchos casos es un mapeo uno a uno. Esto puede parecer una pérdida de tiempo, pero tiene ventajas, especialmente con diseños de modelos de datos más complejos, los modelos de visualización le permiten aplanar los datos para mostrarlos y atribuir propiedades para la validación sin pegarlos en la entidad del modelo de datos. Para obtener más información, consulte el capítulo sobre este tema en el libro ASP.NET MVC in Action.

Answer 2

Dado que existen otras ventajas de exponer entidades (por ejemplo, la validación a través de atributos), yo personalmente las expongo directamente.

Pero supongo que la respuesta correcta sería "depende" ya que siempre hay algunos inconvenientes también (principalmente arquitectónicos).

BTW: puede llamar al cuadro de texto "OneCustomer_LastName" y el enlace de convención de C.M funcionará.