.net - ¿Cuál es su experiencia al abandonar MVVM para la arquitectura WPF basada en UserControl?

architecture prism

Question

Creamos una gran aplicación basada en la Biblioteca de aplicaciones compuestas y MVVM utilizando los controles Infragistics .

Para ahorrar tiempo y hacer que la aplicación sea más sencilla, desechamos el requisito de MVVM . Ahora no tenemos Presenters o ViewModels y nuestras Vistas se han convertido en UserControls simples que se crean así:

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 del problema de la capacidad de prueba y el hecho de que esto "se siente sucio" al hacer WPF de esta manera, solo he experimentado efectos positivos de esta decisión, por ejemplo:

• podemos heredar nuestros UserControls que no son XAML
• utilizamos la cantidad de código que queremos, lo que agiliza el desarrollo
• Al unir los controles infragísticos directamente a nuestra clase de modelo proveniente del servicio web se borraron docenas de pequeños problemas vinculantes que estábamos teniendo con la vinculación de Infragistics a ObservableCollections
• incluso en WPF directo, la falta de ObservableCollections hace que los problemas como no poder crear un menú simple desaparezcan
• estamos reemplazando EventAggregator uno por uno con eventos directos usando UserControls y código detrás, lo que solucionó todo tipo de problemas con los eventos

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

Answer 1

Empecé a hacer aplicaciones de WPF en un patrón de diseño de FFA (gratis para todos) como este y no volveré, 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 una gratificación instantánea .

Considere: 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 algunos de mis problemas más importantes:

• Separación de preocupaciones . Sin él, la navegación por código, la corrección de errores, la extensibilidad y el mantenimiento general se ve seriamente obstaculizado. Agregar una función a una aplicación sería más parecido a un libro de aventuras de elección propia o un ejercicio de física cuántica de lo que realmente se está logrando. Si tiene una forma predecible de construir su aplicación, tiene una manera predecible de trabajar en ella.

  Flexibilidad de la UI . Cuando usé el patrón de FFA, descubrí que mi capacidad para diseñar UI en mis aplicaciones era casi imposible. Demasiadas veces tuve un control que no pude diseñar en Blend. Simplemente daría un borde rojo con una excepción. Algún código subyacente, había usado algo más que no se podía usar en el modo de diseño y que causaba un problema. Pasar a MVVM mágicamente solucionó todos mis problemas de Blend. Si obtengo un borde rojo en Mezclar ahora, SÉ que es un problema con mi código de presentación. Nada más.

Entonces, usar FFA puede hacer que tu V1 salga rápidamente, pero los PHB se preguntarán por qué v1.5 tardará cuatro veces más que v1. Todos hemos estado allí :)

Creo que si quieres hacer algo como esto, trabajaría con controles sin sentido, en los que defines UI "PARTS", lo que lo hace 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 de 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 vista funcionará como solía hacerlo una vez que la incorpore.

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 eventos / código relacionado con la presentación ... Y ... realmente, defiendo MVVM y no doy un @ $ &% sobre testing :)

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 otro myLabel.Text = this.MyLabelText me myLabel.Text = this.MyLabelText .

No me malinterpreten: MVVM es más difícil de seguir y realmente debe saber WPF para lograrlo .

Sin embargo, pierde mucho al no usarlo, incluida la capacidad de utilizar Expression Blend para dar estilo a sus controles y plantillas de datos.

Answer 3

Oye, lo que sea que funcione para ti. 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.

Respetuosamente discreparía (sin voto negativo) con Anderson Imes en un punto: no creo 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.

Escribí un artículo de CodeProject 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.

EDITAR:

La vinculación a eventos no rompe necesariamente el modelo de MVVM si utiliza el controlador de eventos para reenviar el evento a la lógica del controlador en su modelo de vista u otro objeto responsable.

Las ventajas de la vinculación pura de datos radican en que puede crear más fácilmente máscaras de XAML que usen 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

No estoy de acuerdo con esto, he trabajado en una aplicación de negocios a gran escala utilizando los 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 volvió 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 código en código subyacente para resolver algunos problemas (errores en telerik); todo ese código era puramente lógica de presentación.

Answer 6

podemos heredar nuestros UserControls que no son XAML

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

utilizamos la cantidad de código que queremos, lo que agiliza el desarrollo

Code-behind está bien siempre y cuando el código esté relacionado con la vista. es decir. no es la lógica de negocios que desea probar. Separación de preocupaciones y todo.

Todavía 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 necesitas trabajar en Blend, hay una cierta cantidad de tu vista que aún se puede manifestar como código. Solo necesita evaluar las concesiones y tomar decisiones conscientes e informadas.

Al unir los controles infragísticos directamente a nuestra clase de modelo proveniente del servicio web se borraron docenas de pequeños problemas vinculantes que estábamos teniendo con la vinculación de Infragistics a ObservableCollections

Los controles de 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 directo, la falta de ObservableCollections hace que los problemas como no poder crear un menú simple desaparezcan

No entiendo 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 reemplazando EventAggregator uno por uno con eventos directos usando UserControls y código detrás, lo que solucionó todo tipo de problemas con los eventos

Herramienta correcta 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 en aislamiento, vas a tener un buen 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 7

Los defensores 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.