tutorial - wpf xaml
¿Windows Forms es vieja tecnología? (11)
Es hora de escribir la GUI para mi proyecto, y me pregunto qué tecnología usar. Hice la mayor parte de mi desarrollo de .NET GUI en .NET 1 y 2, por lo que conozco Windows Forms razonablemente bien. Soy vagamente consciente de WPF , pero aún no he intentado "entrar en él".
¿Windows Forms está muerto o muriendo? ¿Es WPF una buena tecnología para aprender? ¿Es el futuro, solo una fase o una tecnología que puede caminar de la mano junto con Windows Forms?
Además, cualquier experiencia será buena para escuchar, especialmente de personas que han usado ambas de manera extensa. ¿Cómo encontraste la implementación de una característica similar en ambos marcos?
¿WinForms está muerto o muriendo?
No. No se desarrolla significativamente más (es decir, no hay nuevas adiciones importantes ), pero es totalmente compatible con .NET 4, por ejemplo.
¿Es WPF una buena tecnología para aprender?
Sí.
¿Es el futuro, solo una fase o una tecnología que puede caminar de la mano junto con WinForms?
Se pretende que eventualmente se traslade a WPF, pero también se entiende que existen grandes bases de código escritas en WinForms, y no hay un caso de negocio para volver a escribirlas en WPF. Por lo tanto WinForms sigue siendo compatible.
Además, cualquier experiencia será buena para escuchar, especialmente de personas que han usado ambas de manera extensa. ¿Cómo encontraste la implementación de una característica similar en ambos marcos?
En términos generales, WPF es mucho más expresivo. Si observa los marcos como un conjunto de ladrillos Lego que se pueden juntar de varias maneras, los ladrillos de WinForms son mucho más grandes, cada uno hace mucho, y por lo tanto hay menos formas de juntarlos. Muy a menudo, cuando necesitas algo pero no exactamente como lo hace un ladrillo existente, tienes que escribirlo desde cero. En WPF, los ladrillos son significativamente más pequeños y se pueden combinar de muchas maneras interesantes e incluso sorprendentes.
Para un ejemplo concreto, considere cómo WPF Button es un contenedor que puede alojar contenido arbitrario, no solo imagen + texto como en WinForms, sino absolutamente cualquier otro control WPF o conjunto de controles.
WPF también es mucho más fácil de escribir diseños dinámicos en comparación con WinForms. El último también tiene diseños, pero el problema es que son un PITA real para trabajar en el diseñador visual, y escribir la inicialización de los componentes de WinForms por código es muy tedioso. Con WPF, solo escribe el marcado XAML a mano, y los diseños (y los árboles de control en general) están representados de forma muy natural en XML.
Parcialmente derivado de lo anterior, encuentro que WPF es más fácil de localizar. Por un lado, es porque realmente necesitas diseños dinámicos para la localización (ya que no sabes de antemano la longitud de las cadenas en todos los entornos). La solución de WinForms para esto es considerar no solo las etiquetas de texto, sino también la posición y el tamaño del control, como "propiedad localizable", por lo que se supone que el traductor debe reorganizar los controles en el formulario si encuentra que las cadenas no encajan. En WPF, los diseños dinámicos son el enfoque predeterminado, por lo que el localizador solo se ocupa de las cadenas.
El marco de enlace de WPF es bastante poderoso (aunque sea detallado, gracias a la falta de convertidores en línea) y promueve en gran medida el MVP y, en general, la separación modelo / vista. Esto es posible de lograr con WinForms en 2.0+, y trato de hacer eso allí también, pero es más tedioso, especialmente con respecto al manejo de nulos, y algunas veces puede ser bastante defectuoso .
Un punto de dolor particular es la forma en que el diseñador de WinForms interactúa con el control de la fuente. Hay dos problemas similares aquí. En primer lugar, el diseñador serializa la forma editada como código y, a veces, los cambios menores en el diseño pueden hacer que el diseñador genere un código completamente diferente (esto es particularmente notable si edita barras de herramientas) porque baraja las líneas de código, es decir, en realidad cambió valor de propiedad individual en una línea, pero también reordenado todo. Esto conduce a mucho ruido en la historia (es casi imposible saber qué fue exactamente lo que se cambió cuando se miraron las diferencias), pero lo más importante es que la combinación de tales archivos es un gran dolor de cabeza. Esto suele suceder cuando dos personas trabajan con el mismo formulario al mismo tiempo, y luego una confirma sus cambios y la otra trata de confirmar, descubre que el archivo se modificó mientras tanto, intenta fusionarse, ve las diferencias, Y salta por la ventana más cercana.
Un problema muy similar ocurre cuando utiliza los formularios localizables de WinForms, que envían algunas propiedades a un archivo de recursos. Nuevamente, al diseñador le gusta mucho reordenar los valores de propiedad en el archivo de recursos para cualquier cambio trivial, con los mismos problemas descritos anteriormente.
Ahora en cuanto a las deficiencias en WPF. Una de las más importantes es que es un poco más complicado y puede que no sea familiar para alguien con experiencia solo con WinForms, VCL, VB u otros marcos "tradicionales" similares. Otro problema es que la documentación, en mi opinión, no es perfecta. Por lo general, ofrece una visión general decente, pero rara vez cubre casos de esquina, algunos de los cuales pueden ser muy importantes. Este es el caso de WinForms, también, pero hay menos combinaciones posibles allí, así que también hay menos casos de esquina.
También está el tema de los componentes de terceros. WinForms había existido por mucho tiempo, y hay muchos de ellos disponibles, y muchos de ellos son muy maduros. WPF es comparativamente joven y aún atraviesa problemas de crecimiento, al igual que la mayoría de las soluciones de terceros.
Un motivo especial de mi mascota en WPF es la forma en que suaviza el texto, que la mayoría de las personas perciben como de una calidad mucho peor en comparación con el Windows ClearType simple, especialmente en tamaños de letra pequeños; ver este informe de error para más información. Esto se solucionó en WPF 4, pero aún no se ha publicado, e incluso cuando lo será, es probable que desee mantener el 3.5 SP1 probado y verdadero durante algún tiempo; y la solución no está respaldada.
Aquí hay una buena publicación en el blog sobre WinForms y WPF. La idea general es elegir sabiamente, lo que significa que no hay una ganadora sobre la otra. Cada uno tiene un subconjunto diferente de características.
Tomar la decisión entre WPF y WinForms, sin embargo, es una historia diferente. Claro, WPF es el nuevo hotness y WinForms es viejo y roto, pero ¿es la elección correcta? Obviamente "depende" de la situación y Microsoft continúa entregando y dando soporte a WinForms para que no desaparezca pronto. ¿Cuáles son los factores de peso para elegir WPF sobre WinForms? Karl insinúa las opciones de WPF sobre WinForms en su serie de aplicaciones empresariales de WPF, pero las razones pueden ser sutiles para algunos.
Personalmente prefiero WPF porque empecé como desarrollador web y creo que el XAML de marcado es más natural.
Ciertamente no.
Las Winforms son más fáciles de usar (teniendo en cuenta que aún no conoces WPF) y WPF es un gran alejamiento del modelo de Winforms.
Si desea una GUI simple (formulario estándar) vaya con Winforms. Si quieres algo un poco más llamativo y tienes tiempo, opta por WPF.
Estoy seguro de que llegará un punto en el futuro donde WPF es el estándar de facto. Pero por ahora, me quedo con Winforms si quiero algo rápido y limpio.
Vale la pena mencionar que muchas aplicaciones ya están utilizando Winforms, lo que significa que el trabajo de mantenimiento a menudo tendrá que ver con WinForms, por lo que no se rite todavía.
Comenzamos a usar WPF para un nuevo proyecto y, francamente, es difícil volver a WinForms. Muchas cosas bonitas con las que no puedo ir más.
Sin embargo, un consejo. A pesar de que puedes hacer un diseño mucho más complejo con WPF (como se menciona, un botón, o casi cualquier cosa realmente, puede alojar otras cosas como imágenes, cuadros de texto e incluso más), algunas otras cosas "básicas" que se encuentran dentro de WinForm son difíciles de reproducir . Ejemplo: antes de que saliera el kit de herramientas de WPF, WPF no tenía redes de datos ni un selector de fechas, por lo que tenía que hacerlo usted mismo. Además, aún no tiene MaskTextBox, debe hacerlo usted mismo o descargarlo de terceros. El último en que me topé con el que realmente encuentro anotaciones es con Treeview: las líneas entre las hojas y los padres no se ven.
Dicho esto, todavía es mucho mejor que WinForm en la mayoría de los aspectos.
Creo que definitivamente vale la pena aprender WPF antes de que se vuelva más común, siempre es bueno mejorar su conjunto de habilidades y tener experiencia y el conocimiento de las nuevas tecnologías siempre es una ventaja, especialmente si WPF se va a utilizar más ampliamente en el futuro.
Además, aunque escribir el marcado xaml es muy diferente a crear formularios, no está a un millón de millas de escribir html y probablemente no será una gran salida para ti si has realizado algún desarrollo web.
Si bien WinForms es una tecnología más antigua que no significa que alguna vez desaparezca, todavía tenemos aplicaciones en las que trabajo que están escritas en VB6. Solo la mitad de nuestro departamento de desarrollo trabaja con .NET: estamos divididos en 3 equipos, un equipo todavía está usando .NET 1.1, otro equipo está usando .NET 2 y el equipo en el que estoy está utilizando .NET 3.5 (podría Digamos que somos los afortunados!)
Empezamos a usar wpf en un nuevo proyecto que tenemos.
La nueva aplicación incluye una gran cantidad de código heredado en winforms.
Siempre que queramos usar el viejo diálogo de winforms es posible.
cuando se utiliza para WPF, realmente no desea volver a las formas de ganar. Es mucho más fácil hacer cosas de GUI que te llevarán mucho tiempo en winforms.
De todos modos, toma algo de tiempo aprender las cosas y poder usar todas sus capacidades (no solo la interfaz de usuario, sino también el enlace de datos y los comandos).
Tener a alguien con experiencia que pueda ayudar con la primera arquitectura puede ser muy útil.
WinForms está lejos de morir / morir. WPF es simplemente una forma más nueva de abordar la interfaz de usuario ya que promueve cosas que fueron más difíciles en WinForms. Cosas como separar el modelo detrás de la interfaz de usuario de la interfaz de usuario real para que pueda probarse fácilmente es un factor importante.
Definitivamente vale la pena aprender, pero asegúrate de aprender "la forma WPF" de crear las pantallas en lugar de simplemente encajar tus WinForms. Es una forma diferente de codificar.
WinForms no está muerto o muriendo ... simplemente no pueden proporcionar la misma experiencia de usuario que WPF (sin MUCHO trabajo). Son solo tecnología más antigua.
WPF es una buena tecnología para aprender. Proporciona la capacidad de proporcionar una experiencia de usuario mucho más rica con menos trabajo.
El modelo para trabajar con WPF es definitivamente diferente a WinForms. He usado ambos (WinForms más que WPF / Silverlight) y las transiciones más difíciles para mí fueron:
XAML, que no es tan malo si tienes experiencia con otro lenguaje de marcado como MXML.
El enlace de datos
Manejo de eventos de interfaz (efectos MouseOver, líneas de tiempo, etc.)
WinForms no está muerto. Google "Winforms C # trabajos" y encontrará un montón. WPF es lo mejor, pero aún es relativamente nuevo. No será la corriente principal por otros dos o tres años IMHO.
WinForms probablemente estará presente durante mucho tiempo en entornos corporativos. Funcionan lo suficientemente bien para muchos propósitos. Muchos proyectos se basan en WinForms, y muchas compañías mantendrán esa tecnología durante la duración de los proyectos en lugar de mezclarlos y combinarlos.
Dicho esto, WPF es el futuro. Es una tecnología UI mucho más eficiente, mucho más capaz y que vale la pena aprender.
WinForms y WPF pueden coexistir en una sola aplicación. Esa será probablemente la forma más común para que se presenten a una empresa (eso, y pequeños proyectos de prueba de concepto).
Perspectiva desde 2016:
No suelo recomendar a menudo una pregunta tan antigua, pero pensé que un epílogo podría ser apropiado en esta pregunta. ¿Por qué? Porque incluso ahora (2016), escucho a desarrolladores en entornos corporativos que todavía hacen esta pregunta.
Sí, siete años después, WinForms sigue vivo en entornos corporativos y aún es compatible con Microsoft. Google Trends muestra un lento y constante descenso en el interés desde mediados de 2005, con un interés actual de alrededor de un tercio de los de 2005.
WPF hizo un gran revuelo en 2009, pero nunca se convirtió en el estándar de facto para el desarrollo de nuevas interfaces de usuario. Google Trends muestra un aumento en el interés de WPF desde 2009-2011, y luego declinó más rápido que WinForms. El interés de búsqueda actual es aproximadamente la mitad de los de 2011, pero aún casi el doble del interés de búsqueda actual de WinForms.
Entonces, ¿qué están usando los desarrolladores ahora? Las UI basadas en la web han crecido en popularidad, en gran parte debido al aumento de la navegación móvil. Podría discutir sobre la mejor manera de escribir una interfaz de usuario web (¿AngularJS + WebAPI? ASP.NET MVC? ¿Reaccionar? Todos tienen una tendencia al alza en Google Trends). Sea cual sea la tecnología que use, es difícil negar el atractivo de escribir una IU (de respuesta) una vez y hacer que funcione en casi todos los dispositivos y plataformas. Los servicios de alojamiento en la nube fomentaron el impulso a la web al ofrecer un escalamiento casi instantáneo / infinito con una baja inversión inicial en infraestructura.
Así que hoy, recomiendo vivamente pasar a una interfaz de usuario web, ya que puede mejorar la vida útil de su aplicación, que a menudo debe durar mucho tiempo en entornos corporativos. Alternativamente, si eres un desarrollador basado en Microsoft que realiza desarrollo móvil, Xamarin merece la pena.