2010-05-16 11 views
6

He visto muchas preguntas sobre los méritos de WPF aquí, y esencialmente cada respuesta dice que es de las rodillas de la abeja, pero básicamente cada respuesta también habla de cosas como XAML, en muchos casos diseñadores gráficos y Expression Mezcla, etc. Mi pregunta es, ¿vale la pena entrar en WPF si eres un programador solo trabajando en C# solamente?WPF con código solo

Específicamente, no tengo un diseñador gráfico, ni tampoco un gran talento en esa área; No uso herramientas de apuntar y hacer clic; Escribo todo en C#, no en XML.

Winforms funciona bien en esas condiciones. Es lo mismo para WPF, o resulta que las funciones importantes solo se pueden realizar en XAML, la configuración predeterminada no está pensada para el uso real y debe tener un diseñador gráfico en el equipo para que las cosas se vean bien, etc. ., y alguien en mi posición estaría mejor si se quedara con Winforms?

+1

¿Me equivoco o está realmente orgulloso de negarse a utilizar las herramientas adecuadas? – ima

+0

No creo que _proud_ o _proper_ sean las palabras correctas. Creo que es una cuestión de preferencia. Las herramientas de arrastrar y soltar siempre me dan dolor de cabeza, así que me niego a usarlas. Voy a editar XML a mano si es necesario, aunque prefiero trabajar solo en C# si es razonablemente posible.Me pregunto qué tan bien WPF acomoda estas preferencias. – rwallace

+1

WPF acomodará sus preferencias, pero se le recomendaría encarecidamente que conozca la forma de hacer las cosas de WPF. Tener un diseñador WPF decente con una buena funcionalidad de vista previa podría acortar significativamente el ciclo "modificar -> previsualizar -> modificar". Si "retocar" con la UI es menos doloroso, es probable que disfrute pasar tiempo con él y, posiblemente, salga con diseños más agradables. – R0MANARMY

Respuesta

4

Respuesta corta: es sí, puede hacer WPF con código solamente.

Respuesta larga: La parte de un diseñador la posibilidad de trabajar en la interfaz de usuario y un desarrollador de la funcionalidad es realmente sólo un efecto secundario de la disociación de la funcionalidad de la presentación.

Lo que WPF trae a la mesa de una manera poderosa es el enlace de datos que le permite utilizar una gama más amplia de patrones de diseño. MVVM se ha discutido un poco recently.

  • Los diversos MVVM framework fomentan la convención sobre la configuración, lo que le permite escribir menos código para lograr los mismos objetivos.
  • Este desacoplamiento también tiene el agradable efecto secundario de hacer que su aplicación sea más comprobable (no tiene que escribir pruebas si no quiere, pero al menos la opción está ahí).

El traslado a WPF desde WinForms probablemente valga la pena para usted por un nuevo desarrollo. En teoría, podría seguir haciendo lo que ha estado haciendo con WinForms (solo con nuevas bibliotecas), pero le ofrece la opción de incorporar nuevas herramientas en su desarrollo a medida que se sienta más cómodo con la tecnología.

Si no lo ha visto ya, el BabySmash series de Scott Hanselman es bastante interesante.

3

En mi humilde opinión, vale la pena ir por la ruta WPF, aunque solo sea para asegurar que desarrolles estas habilidades. He jugado con Silverlight, que está basado en XAML, y pude transferir gran parte de ese conocimiento a WPF, aunque SL es un subconjunto.

Y para ser sincero, una vez que te acostumbras, la mayoría de las interfaces de usuario se compilan con la misma facilidad que con WinForms. Y las herramientas son bastante buenas, usar SketchFlow para crear prototipos es útil, y no requiere que tengas habilidades artísticas reales distintas de las que tienes para hacer cosas de WinForms. Creo que de ahora en adelante, solo me beneficiaría aprender más sobre WPF, y creo que ese sería el caso para otros.

+0

Como dices, sin duda es valioso tener la habilidad para diseñar interfaces atractivas. Por otro lado, si uno tiene una preferencia para construir dichas interfaces en C# en lugar de XML, ¿lo acomoda WPF? – rwallace

+0

@rwallace, no es la habilidad de diseñar interfaces atractivas a las que me refiero, sino el conocimiento y la comprensión de WPF, esa es la habilidad a la que me refiero. Definitivamente puede construir la interfaz de usuario en el código, puede adherirse al diseñador en el IDE o puede codificar a mano el XAML o incluso una combinación de todos los anteriores. –

6

Soy una persona de código, y para ser honesto, no importa. Incluso si no sabe nada sobre el diseño gráfico, puede usar el editor en Visual Studio para diseñar una interfaz de usuario. El diseñador presenta un drag & drop designer como Win Forms, por lo que realmente no representa un problema. Aunque soy una persona con código, no tengo ningún problema con xaml, ya que de alguna manera es código nuevamente. Al principio también tuve problemas con el xaml, pero me acostumbré a él, y todo lo que tenía que hacer en el código en Win Forms era bastante fácil en xaml.

La vinculación de datos simplemente es una piedra, no tiene que preocuparse por obtener los datos en la interfaz de usuario, simplemente tiene un ObservableCollection<T> o similar, y una propiedad en el código xaml y todo se hace por usted. ¿Quieres formatear los datos? Simplemente agregue una propiedad de formateo al enlace. ¿Quieres colorear el texto de acuerdo con el valor? Clase de selector de plantilla con 15 líneas de código, selección de enlace y plantilla en el código xaml de aproximadamente 10 líneas. Realmente estoy creciendo para amarlo, y con el tiempo (como con cualquier otra tecnología nueva) te acostumbras y produces cosas atractivas.

1

Digo que WPF puede ser para ti, y si no quieres seguir el camino de xaml y doblo el código solo debes seguir adelante y hacerlo, en xaml ciertas cosas son imposibles pero es la forma preferida de hacerlo diseño, pero nadie te obliga a no hacerlo en el código, sin embargo, si aprendes xaml, producirás elementos de la interfaz de usuario más rápido, luego lo harías con el código, así que eso es algo para recordar.

+0

Gracias, eso suena prometedor. Preguntaré, ¿cómo XAML te permite producir cosas más rápido que en código? He probado tecnologías similares en otros marcos, y no las he encontrado para aumentar mi productividad, ¿pero tal vez WPF sea diferente? – rwallace

+0

XAML es marcado, por lo que se describe una constelación absoluta sin preocuparse por el "timing" correcto, cadenas de eventos y hacer las cosas en el orden correcto. Esto ayuda a mantener las cosas fáciles y fáciles. Los cómputos centrales, etc. siempre permanecerán en su código, al igual que antes. –

3

Todo lo que se puede hacer en XAML también se puede hacer en código debido a que XAML es simplemente una DSL para crear y configurar gráficos de objetos, específicamente los de la biblioteca WPF (System.Windows). Si está creando aplicaciones de línea de negocio, entonces hay muy pocas ofertas de WPF que no están disponibles en WinForms. La diferencia clave es que WPF le permite hacer muchas cosas de manera mucho más fácil y flexible, debido a su modelo de objetos más avanzado.

Creo que vale la pena aprender WPF, pero si quieres hacerlo sin aprender XAML, entonces creo que probablemente te resulte más difícil grok.

También vale la pena considerar que muchos desarrolladores de WPF escriben el XAML a mano (mientras que sus contrapartes de diseño serán más propensos a usar Blend en primera instancia) en parte por necesidad (el diseñador de WPF antes de Visual Studio 2010 no era muy bueno) y en parte porque el modelo de objetos se presta a una expresión más concisa en XAML que en C#. XAML es en sí mismo un lenguaje bastante pequeño, pero el modelo de objetos que se usa para definirlo (el modelo de objetos de WPF) es enorme, y de ahí viene la complejidad.

Si no tiene un motivo convincente para dejar de usar WinForms, no lo haga. Sin embargo, si puede dejar a un lado sus ideas preconcebidas sobre la escritura de código en XML en lugar de C#, entonces creo que podría sorprenderse de cómo este enfoque diferente para construir una interfaz de usuario podría limpiar su código.

0

esto es una publicación anterior, pero ... En mi opinión, no hay límites cuando codifica usted mismo en cualquier entorno y que siempre hay algo que debe descubrirse. Las personas han creado diseños en código durante muchos años en el pasado, pero ciertos factores movieron a la comunidad a crear herramientas gráficas y de interfaz de usuario. Pero, de nuevo, nada dura para siempre y las tendencias cambian rápidamente. También recuerde la transición de la codificación en línea ASP al estilo de composición de disposición de ASP.NET y luego vuelva a estar en línea con ASP.NET MVC. ¿Fue un paso atrás? Ciertamente que no, porque fue respaldado con otras técnicas y herramientas como razor, lenguaje dinámico, carpetas modelo y más. Así que, en realidad nadie puede decirle la forma correcta de trabajar, siempre y cuando siga las reglas y estándares básicos y se dé cuenta de que no es solo código, sino más bien código de hoy, con todos los lambdas, linqs, expresiones, anónimos, DLR etc. Quién sabe? Tal vez sea usted quien cree una nueva forma de expresar e impulsar el contenido.

Cuestiones relacionadas