c# - tutorial - ¿Qué tan malo es la curva de aprendizaje de WPF?
wpf vs windows forms (11)
He leído y escuchado a varias personas que WPF tiene una curva de aprendizaje bastante empinada (según el nivel de conocimiento o experiencia que tenga). Parece que la mayoría de las personas pueden hacer que funcionen los proyectos de demostración o de inicio, y que luego se queden atascados por largos períodos de tiempo en problemas diversos. Tengo curiosidad por lo que específicamente es difícil de aprender o entender (capas, SDK, XAML , enlace de datos, etc.) y si tiene alguna sugerencia sobre cómo evitar / aliviar algunos de esos temas difíciles.
Como puede deducir de mi historial de preguntas, definitivamente he encontrado que es una curva de aprendizaje empinada. Describes mi experiencia casi exactamente. Como estudiante de tiempo completo (en matemáticas y física, no en ingeniería de software) que solo hace programación de WPF para aplicaciones de aficionados, ha sido bastante frustrante. He intentado crear nuevas aplicaciones en WPF, o trasladar algunas de mis aplicaciones antiguas a WPF, y siempre me quedo atascado en una pequeña cosa pequeña que parece excesivamente difícil. Una cosa que no he hecho, básicamente por cuestiones de tiempo, es sentarme con, por ejemplo, un libro o una serie de tutoriales y repasarlos paso a paso. Si eres un desarrollador profesional, eso podría ser mucho más factible y podría hacer que WPF sea mucho más fácil para ti.
Creo que lo más importante que me causa problemas es entender el paradigma Model-View-ViewModel (ver, por ejemplo, esta pregunta mía ). Mientras que en WinForms solo podía arrastrar y soltar algunas cosas en un formulario, desordenar sus propiedades y conectar algunos eventos en el código, ahora tengo que pensar en dividir las cosas en vista, modelo y modelo de vista. Muchos de esos eventos de código de código se convierten en reglas de validación o en cosas de enlace de datos. Probablemente no ayude que ninguna de mis aplicaciones sea realmente aplicaciones de "manipulación de datos"; es decir, no manipulan una base de datos de información del cliente ni nada, donde mucho de esto tendría sentido. En su lugar, es más como "Quiero un cuadro de texto en el que el usuario ingresa un URI, y quiero que el botón que dice ''Descargar'' solo esté habilitado si ese cuadro de texto contiene un URI válido". Pequeñas cosas como esa empiezan a complicarse bastante; Tengo que pensar dónde encaja el URI en mi modelo, dónde encaja en mi modelo de vista, conectar un marco de validación y las propiedades de enlace de datos del botón y del cuadro de texto a todos estos elementos.
Otro problema molesto es la cantidad de cosas que simplemente faltan en el marco. Por ejemplo, ordenar listas de vistas .
Al final, sin embargo, WPF tiene muchas ventajas. El marco de diseño parece mucho mejor que el modelo basado principalmente en píxeles de WinForms. Utiliza fuentes modernas como la interfaz de usuario de Segoe, heh: P. Y sus características de composición también son increíbles, por ejemplo, lo natural que es poner una imagen en un botón (solo hay que poner una etiqueta XAML en la etiqueta XAML del botón, esencialmente); Sospecho que también puede resolver mi problema relacionado con las casillas de verificación con controles dentro de ellos , aunque todavía no lo he intentado.
De las pocas personas con las que trabajé que tuvieron que aprenderlo, realmente recomiendan ir a través de todos los tutoriales de Expression Blend. Eso les dio una buena base en WPF y la mejor herramienta para usar cuando se trabaja con él.
Hay un buen artículo de Karsten Januszewski llamado Hitting the Curve: En WPF y Productivity que podría encontrar interesante:
Seamos claros: WPF viene con una curva. Ahora he visto a un montón de desarrolladores golpear esa curva. Y la curva es empinada. Estamos hablando entre dos semanas y dos meses de curva dependiendo del desarrollador y el nivel de experiencia / intuición que tenga el desarrollador. Habrá momentos de total mistificación y muchos momentos de iluminación. Es al mismo tiempo doloroso y agradable, si el desarrollador se deleita en el descubrimiento de una plataforma de interfaz de usuario profunda y bien pensada. Es a la vez familiar y ajeno. Hay muchas similitudes con otros paradigmas de desarrollo de IU: los estilos se sienten como CSS, más o menos. El código XAML detrás se siente como ASP.NET, bueno. 3D se siente como DX o OpenGL, bueno. Los eventos enrutados se sienten como eventos .NET, bueno. Las propiedades dependientes se sienten como propiedades, más o menos así. La lista podría seguir. Pero además de estas metáforas (de algún tipo) familiares, hay tantos conceptos extraños que deben dominarse: control de plantillas, guiones gráficos, enlaces de datos que vienen a la mente de inmediato. No es una curva trivial y no espere ser productivo en el día 1 o incluso en la semana 1 o incluso en el mes 1.
¡Aunque todo vale la pena! ;)
He jugado con .NET durante más de 4 años, en su mayoría aplicaciones de Windows Forms . La encuadernación no es algo desconocido y trato de usar las buenas prácticas en todas mis aplicaciones de C #. Durante el último mes, he estado aprendiendo WPF para el trabajo y debo admitir que es MUY poderoso, pero mucho más difícil de lograr. Puedes hacer mucho más y lograr algunos diseños geniales con menos esfuerzo, pero solo una vez que sabes cómo funciona realmente y es difícil porque es enorme.
Más aún, la depuración es más difícil, lo que también hace que el aprendizaje sea más lento. El problema creo que es el IDE de Visual Studio que no ayuda mucho en XAML y rápidamente te pierdes algunas de las características de IntelliSense de C # al realizar el enlace u otras cosas que ahora están en una etiqueta XML. Me gusta pero sí, la curva de aprendizaje no es suave.
La dificultad para aprender WPF no es tanto la API como el modelo. Es un modelo mental muy diferente del que usarías con algo como Windows Forms .
En lugar de escribir métodos que rellenan imperativamente un elemento de la interfaz de usuario, generalmente los datos se enlazan a las propiedades de un objeto. Para obtener un comportamiento complejo, generalmente usas algún nivel de composición.
Como ejemplo, si tiene una serie de elementos que desea en una lista, con un fragmento de texto seguido de una imagen. En Windows Forms, obtendrías la lista y la repetirías. Para cada elemento de la lista, crearía el control para el elemento y el texto, y agregaría la imagen, y luego agregaría el nuevo subcontrol a la lista. (El procedimiento exacto puede variar según el tipo de control. Puede agregar SubItems en lugar de solo hacer un control, etc.).
WPF manejaría esto de manera muy diferente. En WPF, en el nivel superior, declararía un objeto contenedor y lo vincularía a la lista.
A continuación, le asignará una plantilla a ese contenedor para que muestre sus elementos. La plantilla es básicamente otro control, que define el posicionamiento de los subelementos, que están vinculados a una instancia de la clase con la que se rellena la lista.
Termina con una sensación muy compositiva, y es absurdamente poderoso. También es un modelo muy diferente al que la mayoría de los desarrolladores están acostumbrados, y hasta que no pueda internalizar el modelo, es muy común tener problemas al tratar de hacer las cosas como lo haría en Windows Forms / etc.
Sin embargo, una vez que te acostumbras al modelo, volver a otras API es doloroso. No porque sean repentinamente difíciles, sino porque sabes lo fáciles que pueden ser las cosas.
Puede ser bastante empinado.
Pasé la mayor parte del mes experimentando con WPF y redactando una maqueta de nuestro producto actual sin desarrollar una intuición para su modelo de enlace de datos o incluso descubrir cómo Microsoft puede usarlo. Me tomó mucho menos tiempo comprender los conceptos básicos de ASP.NET MVC.
[Nuestra aplicación muestra / depende de una gran cantidad de datos en tiempo real, y utilicé el libro Windows Presentation Foundation de Nathan. Quizás otro libro hubiera sido más apropiado.]
Sí, no es una caminata fácil, pero no temas. Lo que pasa con WPF es que está bellamente diseñado para que obtengas una retroalimentación emocional positiva constante (al menos yo lo hice) al aprenderlo. Te gusta sentarte jugando con él y exclamar "WOW" cada pocos minutos;)
Será una de esas respuestas ''depende'', pero de lo que realmente depende es si eres el tipo de desarrollador que intenta mejorar continuamente tus habilidades. Si ese es el caso, entonces todo se reduce a un par de cosas.
Compre WPF Unleashed (hay otros libros disponibles, pero recomiendo encarecidamente este), repase los ejemplos y en unos 2 meses aproximadamente, se preguntará cómo pudo hacer las cosas sin él.
No es ciencia espacial y no hay conceptos de cambio de paradigma que tratar. De hecho, si está acostumbrado a mantener una buena separación entre su lógica y su presentación, debería encajar perfectamente.
Para llegar a un nivel de dominio, probablemente estés buscando entre 6 y 12 meses de juego.
Buena suerte.
Si tiene experiencia con HTML o XML o idiomas similares, no es excepcionalmente difícil, especialmente si tiene experiencia en diseño web. Si viene estrictamente de un fondo de WinForms, la curva de aprendizaje es un poco más pronunciada. Actualmente estoy aprendiendo WPF y, como vengo de una amplia experiencia en desarrollo web, no encuentro los conceptos tan difíciles de dominar para la mayoría de ellos. He encontrado que los videos tutoriales en línea en WindowsClient.net también son excepcionalmente útiles, aunque un poco mal organizados.
WPF es diferente; No hay que alejarse de eso.
Mi principal consejo es que no tengas miedo de XAML; ¡Abrázalo, ahí es donde está el poder!
Dejame explicar:-
Para que sea productivo, prefiero escribir XAML en la vista de texto, ya que puedo crear el diseño simple de la ventana con unas pocas pulsaciones de tecla. Si escribe código con frecuencia, esta es una forma muy rápida de desarrollar ventanas. Luego puedes usar los editores visuales para que se vea bonito.
Si tiene en cuenta que cada elemento de XAML hará " new " ese objeto y que cada atributo de ese elemento de XAML es una propiedad del objeto, puede pensar en XAML como creación de objetos y asignaciones de propiedades. Muy similar a escribir código.
Si pasas demasiado tiempo en el diseñador visual, entonces no puedes apreciar esto, y para algunos esto disminuirá la velocidad de aprendizaje.
Un reciente podcast de Hanselminutes puede interesarte.
También aconsejo encarecidamente que aprenda pronto los conceptos de Vistas y Modelos de vista, incluso si no se suscribe a todo lo que es parte de CompositeWPF ya que esto realmente ayuda.
WPF es fácil una vez que tenga una idea general de cómo funciona, pruebe " WPF: cómo y por qué ". El mayor problema es resolverlo si vale la pena y aún hay muchas aplicaciones que se implementarían correctamente como Windows Forms y un poco de gráficos.
También estaría de acuerdo con el comentario anterior acerca de entrar en XAML: es como un HTML un poco más sofisticado y la única dificultad real es descubrir qué hace qué. En cuanto a atascarse más adelante en un proyecto, ¿no siempre se queda atascado más tarde en un proyecto? Es cuando empiezas a tratar de hacer el 1% que es difícil.