WPF: ¿dónde dibuja la línea entre el código y XAML?

Question

Soy un programador C#/.NET desde hace mucho tiempo pero totalmente nuevo en WPF y en 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 han enviado 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!

Answer 1

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.

Answer 2

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 este blog hace un tiempo here.

Answer 3

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 escribo los de XAML ....

Answer 4

Una cosa que lo haría mira es el patrón de modelo de vista de modelo. 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 que hay en él, pero me gustaría comenzar con las entradas del blog de John Gossman:

• http://blogs.msdn.com/johngossman/archive/2005/10/08/478683.aspx
• http://blogs.msdn.com/johngossman/archive/2005/10/09/478894.aspx
• http://blogs.msdn.com/johngossman/archive/2006/02/26/539598.aspx
• http://blogs.msdn.com/johngossman/archive/2006/02/27/540304.aspx
• http://blogs.msdn.com/johngossman/archive/2006/03/04/543695.aspx
• http://blogs.msdn.com/johngossman/archive/2006/04/13/576163.aspx

Actualización: Sólo quiero señalar a la gente otra Stackoverflow post con un montón de buena información sobre M-V-VM en él.

Answer 5

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 detrás.Maximice el uso de RoutedEvents y Comandos en código WPF.

Answer 6

Como han sugerido otros, 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 denominada ModifiedDate que almacena la última vez que se modificó.

• modelo de vista: convierte la ModifiedDate en una propiedad llamada enumeración ModifiedAge, en función de cuándo se modificó: Ayer, en la semana pasada, en el mes pasado, en el último año, etc.

• Ver: convierte la propiedad ModifiedAge a un color de fondo donde los datos recientemente accedidos 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".

Answer 7

que diría su posible uso como mucho xaml, utilizando Binding, commands, styles, etc. templates que tuvieron que soportar la funcionalidad de guardar y cargar plantillas utilizando XamlReader/XAMLWriter y que sea más fácil para los controles que tienen más xaml.

Answer 8

No pierda de vista el hecho de que XAML es el 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.

Voy a repetir el 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 realizar 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.

Stuff like that.