tutorial - WPF sin XAML

wpf presentacion

Question

Arquitectónicamente, creo que WPF es bastante sorprendente. En general, soy un gran admirador del funcionamiento interno subyacente de renderizado / animación. La flexibilidad de la configuración de creación de plantillas y estilos es bastante impresionante.

Pero aborrezco XAML. Siento que eso complica muchas cosas. Lo he usado en aplicaciones grandes y pequeñas, y muchas veces he tratado de descubrir cómo hacer algo en XAML para el cual el principio subyacente es básico, pero la sintaxis es peculiar. No solo eso, sino que me he preguntado muchas veces cuán pesadas son ciertas partes del análisis / encuadernación. (Sé que está compilado, pero no estoy seguro de cuánto se evalúa aún en tiempo de ejecución)

XAML es solo una forma de crear y cargar el árbol visual. ¿Existe algún marco para simplificar la construcción del árbol visual de una manera no XML, basada en código (pero aún en gran parte declarativa)? Específicamente, me interesan los marcos que mitigan cualquiera de los siguientes problemas al tiempo que retienen un enfoque MVVM:

1. Encuadernación fuertemente tipada. Especifique que ViewModel debe ajustarse a un tipo específico. Supongo que BaseBinding utiliza la reflexión debajo del capó y soy un poco escéptico en cuanto a la velocidad de eso, sin mencionar que los enlaces rotos son molestos.

2. INotifyPropertyChanged más rápida, sin INotifyPropertyChanged binding. Parece que se podría crear algún tipo de BindableProperty<T> y el enlace podría escucharlo directamente en lugar de recibir todos los cambios de propiedad de ViewModel. Y el uso de una devolución de llamada directa versus un argumento de cadena también parece ser ventajoso.

3. Un enfoque diferente para la gestión de recursos; de nuevo, los diccionarios fuertemente tipados de algún tipo podrían ser bastante agradables. Casi me gustaría ver estilos como lambdas o algo para capturar el aspecto fuertemente tipado.

En resumen, ¿los marcos que no están basados ​​en XAML se ajustan bien a MVVM y están fuertemente tipados?

Answer 1

Desclaimer - AMO xaml. Creo que es lo mejor que le puede pasar a la tecnología UI desde ... bueno ... yo quería decir "winforms" pero realmente apestaba, ¡así que desde el comienzo de la historia!

Permítanme desglosar sus requisitos de este marco nuevo y mejorado:

1. Vinculaciones fuertemente tipadas : si bien estoy de acuerdo en que ALGUNAS configuraciones pueden ser específicas para la vinculación específica de una manera fuertemente tipada, con frecuencia me encuentro usando el hecho de que la vinculación es completamente flexible y muy útil. el descubrimiento de propiedades en tiempo de ejecución es una propiedad increíblemente poderosa de Xaml y el mecanismo de enlace. En mi experiencia, aprendes bastante rápido para encontrar y solucionar problemas vinculantes, y los errores de tiempo de ejecución son muy detallados. Puede que no sea ideal, pero es bastante bueno.
2. Encuadernación más rápida : el performance es bastante rápido para la mayoría de las situaciones. Siempre puede proporcionar un ICustomTypeDescriptor para mejorar el rendimiento en casos extremos. En cuanto a esa propiedad enlazable con devolución de llamada, ¿qué tal algún tipo de propiedad de dependencia ? (concedo que la sintaxis es algo que falta). Sin embargo, para la mayoría de los usos, encontré que la interfaz INotifyPropertyChanged es suficiente. El mecanismo de enlace solo se preocupa por el hecho de que hubo un cambio, y funciona muy bien en su forma actual. ¿Por qué te importa cómo el marco resuelve este problema, siempre que funcione bien?
3. Diccionarios de recursos : este es otro problema de implementación que influye principalmente en el marco y en su funcionamiento interno. ¿Por qué te importa cómo se implementan? Ellos trabajan bastante bien.

Sospecho que podrías estar usando demasiado código detrás para resolver problemas que pueden y deben resolverse en Xaml. Lo que lo expone a la forma en que el marco de trabajo resuelve estos diferentes problemas y con el que casi nunca tuve que tratar en WPF. La clara separación proporcionada por Xaml entre "cosas que son la GUI" y "Cosas que son su código" hace que sea más difícil para usted interferir con la UI al usar el Código. Pero WPF proporciona MUCHOS mecanismos diferentes para resolver estas soluciones de una manera elegante mediante el uso de Xaml.

Si no te gusta codificarlo (personalmente no me gusta jugar con la interfaz de usuario, nunca termina). Contrata a un experto de Xaml. Por lo general, tienen mejor gusto en la interfaz de usuario que los desarrolladores de todos modos. Y si no puedes, ¡aprende! es una gran herramienta si te tomas el tiempo para entenderlo. Ningún marco resolverá el problema de alterar su uso.

Answer 2

Esta pregunta definitivamente necesita un enlace a Bling UI Toolkit . Es una biblioteca de alto nivel súper genio para animación y prototipos ricos en UI además de WPF. button.Width = 100 - slider.Value con button.Width = 100 - slider.Value , animación como esta: button.Left.Animate().Duration(500).To = label.Right , un compilador de pixel shader - increíble.

Tristemente, no creo que el proyecto esté siendo trabajado nunca más. Pero muchas ideas muy inteligentes para dar algo de reflexión.

Answer 3

No hay marcos como este para WPF. Las tres cosas que menciona en su lista de deseos serían reemplazos directos (y diferentes) para los componentes ya proporcionados por WPF. Además, si reemplaza los sistemas de enlace y recursos con sus versiones, las cosas que quiera sobre WPF (animación, creación de plantillas, etc.) quedarán inutilizadas, ya que dependen en gran medida del enlace, los recursos, etc.

Aquí hay algunas sugerencias que pueden mejorar su experiencia.
1. Aprender a lidiar con XAML (yo también odiaba sus agallas, pero ahora que estoy acostumbrado es genial)
2. Cree su propia biblioteca que haga que la creación de la IU sea fácil para usted, en código. Después de todo, todo lo que se hace en XAML también se puede hacer en código.
3. Si realmente odias INotifyPropertyChanged y quieres una devolución de llamada, en su lugar usa DependencyProperty. ¡Ningún evento para que lo levante, y puede tener una devolución de llamada y valores predeterminados!
4.) No use WPF. Aunque diga que ama la arquitectura, su lista de deficiencias / "mejoras" deseadas abarca casi todo.

Answer 4

Te apoyo en WPF sin Xaml. Me encantan las capacidades de diseño y encuadernación de WPF, pero también odio XAML. Me encantaría que WPF se pudiera escribir en C # simple, algunas ventajas:

• Los inicializadores Object y Collection podrían reemplazar instancias Xaml. (Es una lástima que xaml prefiera desde arriba hacia abajo que hacia arriba).
• Los conversores de enlace podrían ser solo lambdas.
• Los estilos pueden ser simplemente lambdas que modifican un objeto después de la creación de instancias, sin una sintaxis inflada <Setter> .
• DataTemplates sería simplemente lambdas que crean controles dado un objeto
• DataTemplateSelectors sería simplemente una lambda DataTemplate que llama a otras DataTemplates.
• ItemsControl Sería solo un Foreach que toma una lambda (DataTemplate) y lo vuelve a llamar si se agrega un nuevo elemento a la colección subyacente.
• x: Los nombres serían solo nombres de variables.
• No necesita muchas MarkupExtensions
  • x: estático
  • x: Tipo (especialmente con genéricos complejos también!)
• UserControls serían solo funciones.

Creo que se agregó demasiada complejidad a WPF para permitir su diseño. El desarrollo web ya ha perdido esta batalla desde los viejos tiempos de FrontPage hasta Razor.

Answer 5

> non-INotifyPropertyChanged binding.

Para implementar manualmente INotifyPropertyChanged en su viewmodell o modell es bastante trabajo manual / repitative. Sin embargo, leí sobre estas alternativas

• DynamicViewModel: MVVM que utiliza POCOs con .NET 4.0 : este proyecto tiene como objetivo proporcionar una forma de implementar el patrón arquitectural Model View ViewModel (MVVM) utilizando objetos CLR simples antiguos (POCO) mientras aprovecha al máximo la clase DynamicObject de .NET 4.0. Aprovechando el .NET 4.0 y la clase DynamicObject, podemos crear un tipo derivado de la clase DynamicObject y especificar el comportamiento dinámico en tiempo de ejecución. Además, podemos implementar la interfaz INotifyPropertyChanged en el tipo derivado, lo que lo convierte en un buen candidato para la vinculación de datos.

• Actualizar controles .NET : WPF y el enlace de datos de Silverlight sin INotifyPropertyChanged. Descubre las dependencias automáticamente, por lo que no tiene que administrarlas en su Modelo de visualización. Y funciona con Winforms. Enlace a través del código utilizando eventos.

• notifypropertyweaver : utiliza IL weaving (a través de http://www.mono-project.com/Cecil ) para inyectar el código INotifyPropertyChanged en las propiedades.

  • No se requieren atributos
  • No se requieren referencias
  • No se requiere clase base
  • Admite .net 3.5, .net 4, Silverlight 3, Silverlight 4 y Windows Phone 7
  • Admite el modo de perfil del cliente