¿Cuál es su experiencia con el abandono de MVVM para la arquitectura WPF basada en UserControl?

Question

Hemos construido una aplicación de gran tamaño basado en Composite Application Library y MVVM usando Infragistics controles.

Para ahorrar tiempo y hacer que la aplicación sea más sencilla, desechó el requisito de MVVM. Ahora tenemos ninguna presentadores o ViewModels y nuestros puntos de vista han convertido UserControls simples que son creados como esto:

BaseEditor.cs:

using System.Windows.Controls; 

namespace App 
{ 
    public class BaseEditor : UserControl 
    { 
     public string Title { get; set; } 
     public BaseEditor() 
     { 
      Title = "This was defined in the Base Editor."; 
      Loaded += new System.Windows.RoutedEventHandler(BaseEditor_Loaded); 
     } 

     void BaseEditor_Loaded(object sender, System.Windows.RoutedEventArgs e) 
     { 
      StackPanel sp = new StackPanel(); 
      TextBlock tb = new TextBlock(); 
      tb.Text = Title; 
      sp.Children.Add(tb); 
      this.Content = sp; 
     } 
    } 
} 

CustomerEditor.cs:

namespace App 
{ 
    public class CustomerEditor : BaseEditor 
    { 
     public CustomerEditor() 
     { 
      Title = "This was overwritten by the CustomerEditor."; 
     } 
    } 
} 

Window1.cs.xaml:

<Window x:Class="App.Window1" 
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
    xmlns:local="clr-namespace:App" 
    Title="Window1" Height="300" Width="300"> 
    <Grid> 
     <local:CustomerEditor/> 
    </Grid> 
</Window> 

Aparte de la cuestión la capacidad de prueba y el hecho de que este "se siente sucia" hacer WPF como este, me han sólo se experimenta efectos positivos de esta decisión, por ejemplo:

• podemos heredar nuestra no XAML UserControls entre sí
• que utilizan la mayor cantidad de código subyacente ya que queremos lo que acelera el desarrollo
• adjuntando los controles infragistic directamente a nuestra clase del modelo que viene del servicio web aclaró docenas de pequeños problemas de unión que teníamos con Infragistics vinculante a ObservableCol Lections
• incluso en WPF recta, la falta de ObservableCollections que surjan problemas de not being able to create a simple Menu desaparecen
• estamos sustituyendo el EventAggregator uno por uno con eventos directos utilizando UserControls y código subyacente, que despejó todo tipo de problemas con los eventos

¿Alguien más ha realizado MVVM en WPF ha tenido experiencias similares? ¿Te encontraste con algún problema real a la larga?

Answer 1

podemos heredar nuestros UserControls no XAML entre sí

que no entiendo. ¿Qué pasa con MVVM excluye la herencia?

utilizamos tanto de código subyacente ya que queremos lo que acelera el desarrollo

de código subyacente está bien, siempre y cuando sea de código que tiene que ver con la vista. es decir. no es la lógica de negocios que desea probar. Separación de preocupaciones y todo.

Aún puede hacer MVVM mientras hace todo en código, incluso su vista. MVVM no se trata de cero código detrás. Se trata de separar las preocupaciones y los beneficios que se derivan de eso. Si no necesita diseñar sus vistas en Blend, significa que puede manifestar gran parte o la totalidad de la vista como código. Diablos, incluso si do necesita trabajar en Blend, hay una cierta cantidad de su vista que aún podría manifestarse como código. Solo necesita evaluar las concesiones y tomar decisiones conscientes e informadas.

adjuntando los controles infragistic directamente a nuestra clase del modelo que viene del servicio web aclarado decenas de pequeños problemas de unión que teníamos con la unión Infragistics a ObservableCollections

Los controles Infragistics son extremadamente pobres. Ahí, lo dije. Si es una opción, no los use. Si no es una opción (y he estado en esta posición también), normalmente puede solucionar muchos problemas con comportamientos adjuntos y otras técnicas. Es una molestia, sí, pero no culpe a MVVM: culpe a Infragistics por producir un conjunto de control que está tan en desacuerdo con la plataforma WPF.

incluso en WPF recta, la falta de ObservableCollections crea problemas como el no ser capaz de crear un sencillo menú desaparecerá

que no entienden este punto en absoluto. ObservableCollections es parte de WPF, no MVVM. Y después de leer su pregunta (una vez más, la contesté no mucho después de haberla enviado), diría que esto es solo su incomprensión de cómo funciona WPF: nada que ver con MVVM en absoluto.

estamos sustituyendo el EventAggregator uno por uno con eventos directos utilizando UserControls y código subyacente, que aclararse todo tipo de problemas con los eventos

herramienta adecuada para el trabajo correcto. Si puede usar eventos directos, puede hacerlo ya sea que esté usando MVVM o no. MVVM de ninguna manera requiere el uso del patrón de agregación de eventos, por lo que, de nuevo, su punto no está claro. El patrón del agregador de eventos se puede usar para garantizar que diferentes componentes puedan colaborar en el tiempo de ejecución sin tener dependencias en tiempo de compilación. Al usar eventos CLR estándar, está creando fuertes dependencias entre sus componentes. Si alguna vez quieres usarlos de forma aislada, vas a tener un gran momento.

En resumen, esto no es un gran caso contra MVVM, sino más bien una falta de comprensión. Creo que estás nadando corriente arriba y te aconsejo que le eches un vistazo más de cerca a MVVM. No es una bala de plata o un modelo único para todos, pero puede ayudar a crear una base fantástica para sus aplicaciones WPF/SL cuando se usa correctamente.

Answer 2

Intenté esto y terminé volviendo a MVVM. Terminas con el mismo desorden codificado por eventos que siempre acabaste en Windows Forms. Si nunca tengo que hacer otra myLabel.Text = this.MyLabelText seré feliz.

No me malinterpreten - MVVM es más difícil de seguir y usted realmente tiene que saber WPF para sacarlo.

Pierdes un montón al no usarlo, incluida la capacidad de utilizar Expression Blend para dar estilo a tus controles y plantillas de datos.

Answer 3

Oye, lo que funcione para usted. Es muy fácil ser religioso acerca de esto. Mis aplicaciones se deslizan hacia el código de spaghetti a menos que preste una atención bastante estricta a Separation of Concerns, pero eso no significa que MVVM sea el único camino a seguir. Si tienes una aplicación que funciona, y una que puedes cambiar sin un montón de efectos secundarios en cascada, entonces yo diría que sígala.

Estaría en total desacuerdo (sin voto) con Anderson Imes en un punto: no encuentro que MVVM sea difícil de seguir; Me parece muy fácil. Para mí, es el enfoque más simple y natural para diseñar aplicaciones WPF. Lo uso en el marco de Composite WPF (Prism), que proporciona un marco muy robusto para particionar aplicaciones complejas.

He escrito un CodeProject article sobre la implementación de MVVM en una aplicación real. Con suerte, las personas que acaban de ingresar a MVVM lo encontrarán útil.

Answer 4

Un modelo de vista es bueno porque facilita la unión de datos. La vinculación de datos no cubre todo lo que necesita hacer, por lo que es conveniente algún código adjunto al XAML.

En mi experiencia, una combinación de modelo de vista y adjuntar a eventos parece hacer el trabajo hasta que se pueda elaborar un enfoque más puro si es necesario.

EDIT:

Colocación de eventos no necesariamente romper el modelo MVVM si se utiliza el controlador de eventos para reenviar el caso a lógica de manipulador en su modelo de vista o algún otro objeto responsable.

La unión de datos puros tiene la ventaja de que puede hacer más fácilmente diferentes diseños de XAML que utilizan el mismo modelo de vista. Un ejemplo es tener una máscara de depuración que expone algunos de los mecanismos internos para ayudar en el desarrollo y una máscara de trabajo que es el producto final. Las diferentes vistas XAML pueden vincularse al mismo modelo de vista.

Answer 5

Comencé a hacer aplicaciones WPF en un patrón de diseño FFA (libre para todos) como este y no lo volveré atrás, incluso para proyectos pequeños. Aunque parece que eres más productivo yendo directamente a la IU básica, llegué a la conclusión de que es más una percepción de productividad porque obtienes gratificación instantánea.

Considerar: TextBlock.Text = "HelloWorld". Sin ViewModel para construir, sin pegar las configuraciones de V y VM o de unión. Presiona F5 y vemos "HelloWorld" en todo su esplendor. Mi problema con esto es multifacético. Aquí hay un par de mis mayores problemas:

• separación de las preocupaciones. Sin él, la navegación por código, la corrección de errores, la extensibilidad y el mantenimiento general están muy obstaculizados. Agregar una característica a una aplicación sería más parecido a libro de elección de su propia aventura o un ejercicio en física cuántica que realmente está haciendo algo. Si tiene una forma predecible de crear su aplicación , tiene una forma predecible de trabajar en ella.

  Flexibilidad de la IU. Cuando uso el patrón FFA, encontré que mi capacidad para diseñar UI en mis aplicaciones era casi imposible. Demasiadas veces tuve un control I que no pude diseñar en Blend. Sería acaba de dar un borde rojo con una excepción . Cierto código detrás tenía usé algo más que no era utilizable en modo de diseño causando un problema .Mudarse a MVVM mágicamente solucionó todos mis problemas de Blend. Si obtengo un borde rojo en Mezclar ahora, I CONOCER es un problema con mi código de presentación . Nada más.

Así, utilizando FFA puede obtener su V1 por la puerta rápida, pero las empresas del sector privado se preguntaba por qué v1.5 va a tomar cuatro veces más que v1. Todos hemos estado allí :)

Creo que si quieres hacer algo como esto, trabajaría con controles sin sentido, donde definirías UI "PARTS", haciéndolo muy Blendable. Obtiene una referencia a los controles de la interfaz de usuario a través de OnApplyTemplate. Estos controles son totalmente personalizables y heredables. Es su Vista donde usaría estos controles y extraería los datos del enlace, pasándolos a sus controles impersonales. La Vista, IMO, siempre debe ser un pegamento para que la máquina virtual se vincule a este tipo de controles.

Para los controles Infragistics con los que tiene problemas, suponiendo que esté utilizando Prism, debe hacer un adaptador de región personalizado para él. Esto le permite codificar EXACTAMENTE cómo se agregarán los controles a Infragistics. Sin ataduras involucradas. La inyección de la vista funcionará como solía hacerlo una vez que la incorporas.

He visto a algunas personas tener problemas como estos en MVVM, pero creo que es solo tomar MVVM demasiado literalmente. No todo se vale de un mensajero. Mi aplicación de ~ 40 vistas (y en crecimiento) tiene alrededor de 5 eventos compuestos. Yo heredo los controles, yo uso view injection en cosas que ni siquiera son paneles o controles de contenido. A veces tengo codebehind manejar código relacionado con presentación/eventos ... Y ... realmente, defiendo MVVM y no doy un @ $ &% sobre las pruebas :)

Answer 6

No estoy de acuerdo con esto, He trabajado en una aplicación de negocios a gran escala que utiliza controles WPF, MVVM, WCF y Telerik. Al principio, usar MVVM fue un poco difícil, pero una vez que nos decidimos por nuestro diseño y el marco del modelo View, se hizo muy fácil. La reutilización fue muy fácil de lograr y el tiempo de desarrollo también se redujo.

Además, fue realmente muy fácil cambiar los controles por completo; en algunos lugares habíamos usado controles WPF básicos que luego reemplazamos con controles telerik y viceversa (ya que en algunos lugares no necesitábamos controles telerik pesados ​​como GridView). Puedo decir que si es necesario podríamos haber reemplazado fácilmente todos los controles telerik con otros controles de terceros o controles WPF nativos fácilmente en cualquier momento.

Pero sí, tuvimos que implementar algunas soluciones mientras usamos controles telerik y escribimos algunos códigos en codebehind para resolver algunos problemas (errores en telerik); todo ese código era puramente lógica de presentación.

Answer 7

Los abogados de MVVM exponen su caso. Afirman que la alternativa a MVVM es necesariamente el código de spaghetti. Lo que Edward describe aún sigue un patrón, simplemente no es MVVM. El hecho de que Vistas se vincule a Modelos es similar a MVC. El código detrás puede considerarse el controlador.

Claramente, él siente que los resultados son mejores en términos de esfuerzo de desarrollo Y mantenimiento. Dado que este último es el único argumento válido para un patrón de diseño, el caso en contra de su enfoque no está claro.

Decir "no entiendes MVVM" no es realmente un argumento en contra de su enfoque. Un patrón que es más fácil de entender es mejor que uno que no lo es.