Cómo acelerar el desarrollo de WPF

Question

He estado desarrollando con WPF durante muchos meses. Es un gran marco y puedo hacer cosas sofisticadas y elegantes que hubieran sido mucho más difíciles con WinForms.

Sin embargo, tengo la sensación de que para aplicaciones normales de "línea de negocio" sin requisitos especiales de IU, todavía me lleva más tiempo codificar la IU en XAML que arrastrar y colocar en WinForms.

Por ejemplo, en WinForms, me gustaría simplemente colocar una etiqueta adicional y un cuadro de texto adicional en el formulario y organizar todo (utilizando las líneas de ayuda) hasta que se vea bien. En WPF, comenzaría factorizando las propiedades de la etiqueta existente y el cuadro de texto en un estilo, para poder reutilizarlos; pensar en el elemento de disposición más adecuado, tal vez refactorizar algunos paneles de conexión/paneles de distribución en una grilla (o viceversa); pruebe diferentes valores para los márgenes, etc. Aunque tengo mucha experiencia en WPF, aún me lleva mucho tiempo.

Sé que podría olvidarme de "limpiar XAML" y usar el diseñador de GUI en Visual Studio 2008 (que simplemente posiciona absolutamente todo dentro de una gran cuadrícula), pero me temo que perdería muchas de las ventajas que XAML ofrece al hacerlo.

¿Has experimentado algo similar? En caso afirmativo, ¿qué hizo para acelerar el desarrollo diario de WPF?

Answer 1

Lo que hago todos los días para acelerar el desarrollo de WPF:

1. haga caso de verse y sentirse durante tanto tiempo como pueda. Idealmente, retocar alineaciones y márgenes y definir estilos es lo último que hago.

2. Utilice DockPanel antes de usar una cuadrícula y una cuadrícula antes de usar un StackPanel.

3. Al usar la rejilla, tamaño de estrella de todo. Volveré y arreglaré esto más tarde, pero durante la creación de prototipos, tener una idea clara de cuántas filas y columnas tiene en realidad la Grilla es enormemente útil.

4. Prototipo en Kaxaml, acabado en Expression Blend, prueba en Visual Studio. Averiguar una metodología para esto ha tomado mucho tiempo, y todavía es un trabajo en progreso. Pero Kaxaml es ideal para ver rápidamente cómo se comportará un prototipo XAML, y Blend es ideal para trabajar con los elementos visuales y encapsular elementos en los controles y estilos del usuario.

5. Al usar Mezcla, no cree diseños en la mesa de trabajo, créelos en el contorno del objeto. Cuando estoy desarrollando una IU de WPF, la jerarquía de objetos es cien veces más importante que cómo se ve en la pantalla. Todavía estoy aprendiendo a hacer esto, y parece posible que una vez que sea lo suficientemente bueno en eso ya no necesite hacer prototipos en Kaxaml.

6. Trabaja en la cosa más pequeña posible. Esto requiere mucha disciplina. Tengo un gran archivo XAML complejo grande, y decido que necesito editar la plantilla de un control Lo primero que debe hacer es crear un pequeño archivo XAML con ese control y editar la plantilla de control allí. La tentación de trabajar así in situ es sólida, ya que la edición de la plantilla de control está a solo un clic de distancia. No lo hagas

7. Ni siquiera piense si debo desarrollar o no un modelo de vista para mi pequeña y pequeña aplicación. Sí, debería.

8. Learn Blend. De verdad, realmente aprende. Aprenda qué significan todos los pequeños íconos que rodean el objeto seleccionado y preste atención a ellos. (Aquí hay un atajo: no establecí los márgenes en esa cosa, pero Blend sí. Esa es la respuesta al 30% de mis preguntas "¿qué demonios está haciendo Blend ahora?"). Use la interfaz de usuario de Blend incluso si yo sé sería más rápido editar el XAML a mano. Esto también es una cuestión de disciplina, resistir la tentación de hacerlo ahora para poder mejorar mi capacidad de hacer más de eso más tarde.

Answer 2

Si utiliza VS2010, creo que el diseñador visual para XAML es mejor ahora y creo que trae el tiempo de desarrollo más en línea con el desarrollo clásico de winforms.

Si aún necesita establecer el destino de .NET 3.5 puede configurar la solución para compilar a 3.5 en lugar de 4.0. Esta podría ser una buena opción para usted si aún no usa VS2010.

Answer 3

Eso es como decir "Las manzanas en rodajas son fáciles de hacer, pero la tarta de manzana sabe mejor. ¿Cómo puedo hacer la tarta de manzana con tanta facilidad como puedo cortar manzanas?" Bueno, puedes hacer que sea más fácil usando cortezas de tarta prefabricadas o comprar manzanas precortadas, pero nunca será tan fácil, porque admitámoslo, estás haciendo algo que es mucho más complejo y potencialmente más sabroso.

Parece que hacer estilos te detiene. Puede comenzar mucho más rápido si acaba de importar los mismos estilos con cada proyecto. Usualmente vuelo una vez que tengo todos mis estilos hechos.

De lo contrario, la única manera de que sea tan fácil como arrastrar y soltar el diseñador de WinForms es utilizar el diseñador de arrastrar y colocar WPF.

Answer 4

Siento tu dolor ... Cada vez que agregamos un campo nuevo en la base de datos, tenemos que hacer otro TextBox/ComboBox en el formulario. Descubrí que usar Expression Blend me permite ser mucho más rápido al diseñar el formulario. La desventaja es que usar Blend tiende a crear más xaml que escribirlo a mano, por lo que termino limpiando un poco el xaml.

Al final, Blend es un diseñador mucho mejor que Visual Studio (incluido en 2010), por lo que es mucho más rápido hacer su trabajo de diseño en Blend, y el trabajo de desarrollo en VS. (sólo mis dos centavos)

Answer 5

Mi mayor reto en este momento es que estoy constantemente pensando en maneras que la interfaz de usuario podría estar compuesto de forma dinámica con las plantillas de datos, que a menudo puede interponerse en el camino de las soluciones más simples cuando no se requiere la mayor flexibilidad . Aparte de eso, me he vuelto más rápido ahora que me estoy acostumbrando a los diferentes contenedores y sus peculiaridades. Es una tecnología tan radicalmente diferente que tomará tiempo antes de que desarrolle el conjunto de herramientas mentales adecuado para mis tareas cotidianas de IU, especialmente porque todavía necesito usar WinForms regularmente. Me imagino que es solo cuestión de tiempo, sin embargo, antes de tener patrones estándar en mente, puedo implementarlos rápida y fácilmente.

Answer 6

He estado usando WPF durante un par de años: para una velocidad óptima, desactivo la vista de diseño, uso fragmentos, intellisense intensamente (y, por supuesto, ReSharper).

Y luego hago las cosas simples - He descided para utilizar el diseño estándar para casi todo - es decir. bit de pantalla principal -> DockPanel, ToolBar acoplado arriba -> snippet.

Pantalla emergente -> DockPanel, barra superior ToolBar, personalizada Parte persistente parte inferior acoplada (botones Guardar y Cancelar) - propiedades del modelo de vista -> UserControl con grilla, etiquetas y propiedades.

Para diseñar, primero haga eso cuando tenga al menos 3 pantallas para cada tipo - cree diccionarios de recursos para cada tipo. Definir estilos comunes - Bloque de texto de cabecera, etc. Importar ResourceDictionary en cada pantalla y aplicar estilos.

Aplicar colorante, márgenes, relleno, etc. en App.Xaml con estilos sin clave.

No puedo pensar en una manera más rápida. Al menos para mí, realmente no necesito pensar mientras lo hago de esta manera (entonces, puedo usar mi capacidad intelectual más tarde para las cosas complejas) - y da un "aspecto LOB" consistente que es relativamente fácil de estilo, tema y cambio más adelante. Básicamente es una cuestión de mecanografía.

Answer 7

El consejo sobre VS2010 es muy bueno; su diseñador visual es realmente útil, en comparación con el diseñador XAML de VS2008, que fue menos que inútil.

La máquina de relaciones públicas de Microsoft empuja el patrón "Model-View-ViewModel" extensivamente para aplicaciones de línea de negocios, hasta el punto en que realmente recomiendan cosas que pueden perder el tiempo.

Do no gastar horas tratando de meter todo en XAML, a menos que su empresa o cliente tenga procedimientos que lo requieran. Si puede codificarlo más rápido en VB o C#, y el código es aún mantenible, comprobable y legible, hágalo.

Do no convertirse en un purista MVVM; ni siquiera Microsoft ha descubierto el equilibrio apropiado para este patrón, e incluso con las cosas de Silverlight 4, no han presentado un buen conjunto de herramientas de desarrollo o mejores prácticas para el patrón, a pesar de que ya han pasado casi cinco años desde primero fue propuesto; Todavía hay razones muy válidas para abandonar ICommand e INotifyPropertyChanged a favor de simplemente llamar a un método en su ViewModel desde el código subyacente. Además, ningún experto de WPF/Silverlight que no sea de Microsoft que haya escuchado en los últimos meses ha fallado al decir: "Todavía no estoy seguro acerca de MVVM, no soy purista".

Encuentre un equilibrio y use XAML para lo que le funciona, y C# o VB para lo que funciona para usted. A los desarrolladores de MS en sus blogs les gusta llamar a XAML "markup", y C# o VB es "código, desafortunadamente". Bueno, si lo estás escribiendo o dibujando, todo es código, y la verdad es que todo lo que XAML se interpreta y luego se convierte en C# o VB en archivos que no puedes ver o editar fácilmente, antes de que se compilen . (Por ejemplo, Application.g.vb se genera desde Application.xaml como una clase parcial.)

Existen construcciones XAML como animaciones y guiones gráficos que tienen muchas líneas para trazar en XAML, pero en los lenguajes de procedimiento solo puede tome una o dos líneas de código y, de hecho, sea más fácil de leer, especialmente si la animación responde a un evento solo bajo ciertas condiciones. Haz lo que funciona mejor.

Además, si está programando y sigue atacando excepciones en tiempo de ejecución que no tienen sentido, retroceda un paso, encuentre una respuesta alternativa que lo ponga en funcionamiento e impleméntelo. La mayoría de los errores XAML no pueden ser capturados por Intellisense o el compilador. Es posible golpearse la cabeza durante semanas contra un problema XAML, que puede codificarse en C# o VB con una unión temprana en un tiempo comparativamente mucho más corto.

En resumen, relájese y codifique sus mejores prácticas, utilizando las herramientas VS2010, y debería poder aumentar la velocidad.