2011-01-07 9 views
9

Quiero saber por qué deberíamos usar MVVM para implementar la aplicación Silverlight. ¿Cuáles son sus ventajas?¿Por qué debería usar MVVM en la aplicación Silverlight?

No hacemos la prueba unitaria para ViewModel, entonces quiero otras razones.

continuación son mis preguntas acerca de algunas ventajas la gente suele decir:

1.Loosely acoplados: Cuando usamos MVVM, una vista dependen de modelo de vista pero no un punto de vista, por eso que se acopla libremente?

2.Si proporciono métodos públicos en un código subyacente, también pueden proporcionar reutilización.

+0

Si proporciona propiedades y comandos en un código subyacente y se unen mediante '= this.DataContext esto;', que es un modelo de vista demasiado . Simplemente no use un código como 'this.firstNameTextBlock.Text = this.CurrentItem.FirstName;' – vorrtex

Respuesta

4

Bueno, la unidad de la capacidad de prueba de la vista-modelo es una ventaja significativa, por lo que se perderá en ese beneficio. En cuanto a los otros dos:

débilmente acoplados

Sí, la vista qué se basan en la vista-modelo. Deben estar conectados de alguna forma para cumplir la función de la aplicación. Como resultado, no se pueden desacoplar. Las únicas opciones son estrechamente acopladas o débilmente acopladas o en algún punto intermedio. Con MVVM su modelo de vista interactúa con su vista de una manera muy limitada: básicamente solo objetos, propiedades y comandos. Compare esto con hacer todo en el código subyacente donde la vista y su control son esencialmente inseparables.

Reutilización

Si ningún código en su código subyacente es reutilizable lo suficiente como para merecer ser pública, que se puede sacar del código subyacente y se pone en una clase de propósito general. El problema es que lo que queda después de eso no es reutilizable.

Si no desea adentrarse en la inmersión profunda de MVVM, puede obtener algunos de los beneficios de MVVM centrándose en el enlace de datos. Después de conocer los beneficios de la vinculación de datos, puede reconsiderar los otros beneficios de MVVM.

4

No hacemos Prueba de la unidad de modelo de vista,

Con MVVM, no se trata sólo de las pruebas unitarias modelo de vista. Lo ideal es que su VM sea muy delgada y solo tenga las propiedades que necesita la vista. Por lo tanto, no es realmente necesario probar la máquina virtual.

Pero, sin una máquina virtual, ¿cómo se hacen las pruebas funcional/funcional en las distintas capas? En Silverlight, para facilitar las pruebas, debe usar comandos, en lugar de escribir código en archivos de código subyacente. Esto le permite simular clic de botón y otros eventos GUI mientras prueba la unidad. Usando el patrón MVVM junto con los comandos, puede probar todo el código C# (no xaml), hasta UI (Converter, VMs, etc.).

Si proporciono métodos públicos en un de código subyacente, sino que también pueden proporcionar reutilización.

No entrando en detalles de cómo es un mal diseño, quiero preguntarle, ¿Cómo proporciona eso reusablity? Si crea un control de usuario, ¿la clase de código subyacente es un control? ¿Desea crear instancias de su control y usarlas? Esto es como decir que por qué necesitamos métodos de miembro, podemos simplemente crear métodos públicos estáticos y acceder a ellos. Tengo la firme opinión de que si no queremos utilizar el enlace automático proporcionado por WPF/Silverlight, entonces es mejor NO usar estas tecnologías. Y para explotar todas las capacidades de enlace, MVVM es esencial.

¿por qué está ligeramente acoplado?

VM es en gran medida parte de su punto de vista. No está desacoplado de la vista. Como ya he dicho, su máquina virtual debe ser lo más delgada posible, con solo las propiedades públicas que necesita su vista. La lógica de su empresa estará desacoplada de su vista (y VM).

1

Respondo cómo utilizo el patrón MVVM. MVVM es mejor en los siguientes escenarios:

1 Si varios controles están vinculados con una sola propiedad.

MVVM:

<TextBlock x:Name="text1" Visibility="{Binding IsSomePropertyTrue, Converter={StaticResource VisibilityConverter}"/> 
<TextBlock x:Name="text2" Visibility="{Binding IsSomePropertyTrue, Converter={StaticResource VisibilityConverter}"/> 

puedo añadir rápidamente un control similar o eliminar un control existente.

Comparar con código subyacente:

public string IsSomePropertyTrue 
{ 
    set 
    { 
     //... 
     text1.Visibility = value; 
     text2.Visibility = value; 
    } 
} 

2 En lugar de un multi-convertidor de

pública cepillo StateColor { obtener { si (== this.State State.Edited & & this.IsPriority) return new SolidColorBrush (Color.FromArgb (255, 0, 255, 0)); // ... }}

<sdk:DataGridTemplateColumn.CellTemplate> 
    <DataTemplate> 
     <TextBlock Background="{Binding StateColor}" Text="{Binding State}"/> 
    </DataTemplate> 
</sdk:DataGridTemplateColumn.CellTemplate> 

3 Como un modelo de elemento de controles como ListBox o cuadrícula de datos. Por ejemplo, si quiero crear una lista de elementos con un botón para quitar cerca de cada elemento, crearé un control ItemView y una clase ItemViewModel.

<ItemsControl ItemsSource="{Binding SomeItems}"> 
    <ItemsControl.ItemTemplate> 
     <DataTemplate> 
      <view:ItemView DataContext="{Binding}"/> 
     </DataTemplate> 
    </ItemsControl.ItemTemplate> 
</ItemsControl> 

4 Copia de un datos de una vista a otra:

public JournalEntryViewModel(SalesOrderViewModel vm) {} 

5 ViewModel pueden heredar CLR-clases e implementar interfaces (INotifyPropertyChanged o INotifyDataErrorInfo).

También uso MVVM para reemplazar eventos con comandos o propiedades. Y el uso de las fuerzas de ViewModels para llamar a las propiedades por nombres inteligibles.

0

Lo que también resulta interesante en MVVM es el enlace automático dinámico.

Imagine que su modelo de vista tiene propiedades como esta: bool IsFirstNameVisible, bool IsFirstNameEnabled, string FirstName, double FirstNameWidth, etc.

En su archivo XAML, defina TextBox con x: Name = "FirstName" y llame a su carpeta dinámica MVVM. Este inspecciona su clase de modelo de vista a través de la reflexión, busca qué propiedades ha definido y las vincula dinámicamente a propiedades de control similares con el mismo nombre, aplicando convertidores de valor si es necesario.

En este caso, obtenga XAML muy limpio, sin expresiones y convertidores de enlace de datos de un kilómetro de largo.

Eso es lo que hace mi biblioteca MVVM.

0

Separación de personas de Conerns. Separación de intereses.

Olvídese de las pruebas unitarias (me encanta, pero esa no es la cuestión aquí). Olvídate de la reutilización (¿realmente reutilizas los modelos de vista? No, seamos realistas aquí).

Se trata de la Separación de preocupaciones y poner el código y la lógica donde corresponde. La idea general es mantenibilidad; poder hacer cambios en el código a medida que evoluciona con el tiempo sin romper otras cosas y sin convertir todo en una gran pila de espagueti.

MVVM, hecho correctamente, permite que su código se separe en porciones lógicas que tengan sentido y permita una nueva refactorización y el cambio a medida que cambien los requisitos de la aplicación. Es más fácil encontrar donde algo es cuando necesita hacer un cambio. Intenta escribir cualquier aplicación a medio camino compleja y luego dejarla sola durante un mes, luego volver a ella y tratar de hacer cambios significativos. Una aplicación adecuadamente estructurada con uso juicioso de MVVM es mucho más fácil de asimilar después de un despido, y es mucho más fácil hacer cambios.

1

Fui uno de los primeros en adoptar WPF y puedo decirle qué me hizo elegir MVVM (y esto se aplica más o menos a Silverlight también). Para el proyecto en el que estaba trabajando, tuve que crear una pantalla que permitiera a los usuarios suscribirse a notificaciones dentro del sistema. Este fue un proceso de 3 pasos:

  1. El usuario tenía que buscar el elemento que querían ser notificado sobre
  2. Tenían para seleccionar el elemento y complete las opciones adicionales en relación con la suscripción
  3. El sistema tenía para proporcionar un resumen y permitir al usuario confirmar o editar la suscripción.

Después de implementar la funcionalidad la primera vez (sin MVVM), me dijeron que debemos excluir de los elementos de búsqueda que ya estaban suscritos por el usuario.

Después de hacer esa corrección, me informaron que teníamos que darle al usuario una vista previa en vivo de la suscripción según las opciones.

Por entonces empecé a notar que algunos de estos cambios se podían extraer y facilitar si no tenía que lidiar con la manipulación de la interfaz de usuario cuando cambié la lógica. Nunca había seguido intencionalmente MVVM, pero me di cuenta de que la abstracción que hice coincidía con el patrón MVVM.

Es por eso que recomiendo el patrón. Simplifica la tarea de cambiar la lógica que impulsa la interfaz de usuario al separarla de la interfaz de usuario. También recomendaría que no apliques hasta que lo necesites. El uso de MVVM tiene un costo, pero se amortiza sobre el costo de cambiar la lógica de UI.

1

Sin MVVM, su código de aplicación Silverlight muy pronto se convertirá en desorden incontrolable

Cuestiones relacionadas