c# - tutorial - WPF: ¿Dónde trazas la línea entre el código y XAML?

wpf xaml tutorial (8)

Al construir UserControls trato de Xamlize tanto como sea posible.

Un consejo que encontré en el campo es que la creación de ControlTemplate y DataTemplates a mano es realmente un dolor en el *** ... Siempre los escribo en XAML ...

Soy un programador de C # / .NET desde hace mucho tiempo, pero totalmente nuevo para WPF y el espacio de nombres System.Windows.Controls y XAML. Cuanto más aprendo al respecto, más me doy cuenta de que puedes hacer casi toda tu interfaz gráfica de usuario y el manejo de eventos de pegamento en XAML o en código (por ejemplo, código C # o código VB.Net).

Mi pregunta es para aquellos que han estado trabajando en WPF por más tiempo e, idealmente, aquellos que enviaron aplicaciones con él. ¿Dónde encontraron que era el mejor lugar para ''trazar la línea'' entre XAML y el código? ¿Usaste XAML donde pudiste? ¿Solo cuando interactúas con diseñadores de UI no codificadores?

¡Cualquier consejo en esta área sería extremadamente útil para mí y para otros programadores que acaban de entrar en la programación de WPF y están paralizados por todas las elecciones que podemos hacer!

Como otros han sugerido, intente seguir el patrón Model-View-ViewModel. ¡Sin embargo, está bien poner cosas en el código detrás! La regla es que si está relacionado con "Ver", lo pones en el Xaml o en el código subyacente (lo que sea más conveniente para ti). Si se trata de una lógica comercial relacionada con la forma en que el usuario interactúa con el sistema, entonces debe pertenecer al ViewModel. Si solo se trata de una lógica comercial que no se relaciona con la interacción, pertenece al Modelo.

Ejemplos de cada uno serían:

Modelo : define una propiedad llamada ModifiedDate que almacena la última vez que se modificó.
ViewModel : convierte el ModifiedDate en una propiedad de enumeración llamada ModifiedAge, según cuándo se modificó: Ayer, En la última semana, En el último mes, En el año pasado, etc.
Ver : convierte la propiedad ModifiedAge en un color de fondo donde los datos a los que se ha accedido más recientemente se resaltan en amarillo brillante, y los datos a los que se accede menos recientemente son más beige-caqui-gris que su diseñador insiste se llama "Meadow Lark Lilly Flowerpot".

Cuando sigue un patrón adecuado, como Mode-View-ViewModel , tendrá la oportunidad de hacer más en el lado XAML y menos en el código subyacente. Maximice el uso de RoutedEvents y comandos en el código WPF.

Diría que utilizo tanto xaml posible, usando Binding , commands , styles , templates , etc. Tuve que admitir la funcionalidad de guardar y cargar plantillas usando XAMLReader / XAMLWriter y es más fácil para los controles tener más xaml.

No pierda de vista el hecho de que XAML es un código . Es declarativo y todo eso, pero sigue siendo un lenguaje de programación. De hecho, pasa por una conversión a C # o Visual Basic antes de que se convierta en IL para que el compilador de .NET lo muerda.

Me haré eco del comentario de Scott Whitlock: MVVM es una excelente manera de separar las preocupaciones y centrarse en los detalles arquitectónicos. Está muy bien poner cosas en tu código subyacente, especialmente las cosas que describe. Si no tiene un requisito para separar al diseñador del desarrollador, entonces adapte el patrón MVVM a sus necesidades específicas; no intentes forzarte a ser puro o idealista al respecto.

También es perfectamente correcto colocar las llamadas a los métodos de su ViewModel directamente en el código de Ver detrás, si no necesita la flexibilidad de mandar con las clases de ICommand. O bien, si sabe que la Vista que está haciendo siempre estará vinculada a la clase de ViewModel que está creando. O puede llevar las cosas un paso más allá, definir una interfaz para su ViewModel y vincular solo a las implementaciones de esa interfaz. Luego, puede cambiar el ViewModel siempre que lo desee.

Cosas como esas.

Otro consejo es separar XAML en funcional y estético. Los desarrolladores suelen trabajar en el XAML funcional, mientras que los diseñadores se preocupan principalmente por la estética. Esto mantiene el XAML funcional muy fácil de asimilar, lo cual es importante porque los desarrolladores a menudo necesitan editar dicho XAML. Aesthetic XAML normalmente es editado por diseñadores que utilizan herramientas, por lo que su pulcritud y verbosidad es un problema menor.

Hice un poco de una publicación en el blog sobre esto hace un tiempo here .

Un consejo es no declarar controladores de eventos en XAML. En su lugar, nombre sus elementos y adjunte controladores de eventos en el código subyacente. Eso ayuda a mantener una separación limpia entre el diseñador y el desarrollador.

Una cosa que miraría es el patrón modelo-vista-vista. Es un patrón muy elegante que naturalmente separa todo en buenos cubos ... incluyendo tu xaml.

Por ejemplo, le ayuda a mantener un límite claro entre el desarrollador y el diseñador, e incluso permite el desarrollo impulsado por pruebas.

Hay un montón de información por ahí, pero comenzaría con las publicaciones de John Gossman en el blog:

Actualización: solo quiero apuntar a las personas a otra post con mucha información buena en MV-VM.