none
Consulta acerca de encarar un proyecto en WPF XBAP RRS feed

  • Pregunta

  • Buenas tardes, me gustaria saber si no voy a cometer un error.

    Cuento con una aplicacion en VB6, que lo que haces es levantar estructuras de datos en SQL server y a traves de una configuracion, debuja las pantallas en forma dinamica y luego permite actualizar informacion, enviando la misma a store procedure.

    La aplicacion hay que migrarla y estuve haciendo algunos cursos y tambien leyendo bastante.

    Los puntos importantes a cubrir que actualmente no contamos son:


    Que la aplicacion no haya que instalarla en cada maquina.
    Que siga manteniendo la flexibilida y modo de uso, como lo hace VB6 actualmente.
    Que sea una plataforma moderna.

    Datos estos puntos, a mi se me ocurrio que WPF (XBAP), podria cumplir con las exisgencias presentadas.

    La pregunta es, esta bien, la performance sera buena, ya que es una aplicacion WEB, pero que en realidad corre en el cliente y se comunica con WCF para la lectura de datos ??

    Les dejo la pregunta y espero que me puedan ayudar a tomar una decision.

    Saludos
    Eduardo

     

    jueves, 17 de marzo de 2011 15:31

Todas las respuestas

  • Hola Eduardo,

    Si no necesitas acceso a los recursos locales del sistema, yo usaria Silverlight, es más ligero y compatible que WPF XBAP y ganas el poder ejecutar la aplicacion tanto en windows como en Mac OS X, además Silverlight dispone de un modo de ejecución llamado OOB (Out Of the Browser) que permite ejecutar la aplicacion fuera de navegador tanto en Windows  como en Mac OS X.

    si quieres ver un ejemplo de aplicación hecha de esta forma descargate Seesmic 2: www.seesmic.com  veras que es una app muy chula y está creada en silverlight.

    Un saludo!


    MCTS .NET Framework 3.5 Windows Forms Application Development
    MCTS .NET Framework 3.5 Windows Presentation Foundation
    Visita mi Blog en Geeks.ms
    Sigueme en Twitter
    viernes, 18 de marzo de 2011 13:37
    Moderador
  • Aunque a primera vista Silverlight parezca una elección más atractiva, incluso en la versión 4, cosas que en WPF se dan por sentadas en Silverlight suponen más de un dolor de cabeza. Si a esto le añadís que al ser un subset de WPF hay cantidad de funcionalidad no está disponible, es posible que os veáis en la tesitura de tener que mover parte de la lógica al servidor porque no podáis resolver ciertos escenarios en el cliente.

    De todas formas, sin conocer más sobre la aplicación en VB6 esto es más ponerte sobre aviso que otra cosa.

    Otra cuestión sería, tanto si finalmente usáis XBAP como Silverlight, la dificultad y los problemas que os va a ocasionar incluir asincronicidad en la aplicación.

    lunes, 21 de marzo de 2011 18:40
  • cadessi

    ¿Problemas en silverlight para asincronidad? Perdoname, pero de eso nada, y en estos momentos con Silverlight 4, a no ser que necesites acceso al disco duro o al registro de windows, el resto lo puedes realizar perfectamente, ademas, en este caso, hablamos de una aplicación de negocio en vb6, con lo cual vamos a tener que desarrollar un backend con servicios wcf si o si, por lo que no sería un problema.

    Al contrario, al usar silverlight, estamos ganando en agilidad de despliegue y compatibilidad multiplataforma,

    Trabajo diariamente con Silverlight y WPF, creeme, esto ya no es Silverlight 2. Hoy en día Silverlight 4 es tan capaz como WPF de desarrollar aplicaciones de negocio, siempre y cuando no necesitemos acceder a recursos locales.

    Un saludo!


    MCTS .NET Framework 3.5 Windows Forms Application Development
    MCTS .NET Framework 3.5 Windows Presentation Foundation
    Visita mi Blog en Geeks.ms
    Sigueme en Twitter
    martes, 22 de marzo de 2011 8:24
    Moderador
  • Hola Eduardo


    Una migración de estas características hay que analizarla muy bien, en concreto se pregunta que tecnología es la mejor, pero la tecnología “es lo de menos” entre otras cosas por que las que propones son las mismas, es decir tanto XBAP como Silverlight están basadas en WPF.

     

    Ambas tecnologías se basan en un modelo de presentación con toda la funcionalidad que ello conlleva, y ambas tecnologías trabajan bajo el framework .NET, de modo que a fin de cuentas para toda la arquitectura solo tienes una opción “.NET”, de echo otras tecnologías como Winforms solo se diferencian de esta en lo relativo a la presentación, ya que el framework, es el mismo y es mas, si la arquitectura estuviese separada en capas lo sufientemente abstractas, no haría falta tocar nada del nucleo y tan solo se usaría WinForms, WPF, Silverlight, ASPNET, etc. para mostrar datos al usuario (Lo que suele ser una capa de presentación) y si que es aquí donde deberías de seleccionar una u otra para adaptarla a las necesidades y/o requisitos de la aplicación.

     

    Bien, una vez dicho esto, deberas analizar el actual estado de tu proyecto y ver como esta dividida la arquitectura, dependiendo de la escalabilidad, como minimo deberías de disponer o poder separala en 2 capas, una de presentación y otra para el nucleo, lógica o como quieras llamarla. Este es un minimo que debería de disponer cualquier aplicación hoy dia, ya que generalmente suele existir otra capa que es de acceso a datos, pero hoy dia con ORMs como Entity Framework, la capa de acceso datos te la suministra el.

    (Lo dicho aquí es una base muy sencilla, obviamente esto puede llevar toda la miga que se quiera y siempre basada en las necesidades y/o requisitos de la aplicación, hay veces que menos es mas, no por crear 100 capas una aplicación va a disponer de mejor mejor o peor arquitectura. Y esto mismo se puede extrapolar a toda parte de un software).

     

    Según comentas, quieres una aplicacion distribuida, esto se puede hacer con la tecnología que quieras, pero dependiendo de donde quieras que resida el nucleo de la aplicación (servidor común o clientes) deberías de encarar un tipo de arquitectura para la aplicación con los pros y los contras de cada parte.

    De modo que si comentas un poco de que va la aplicación se pueden dar ideas para implementarla.

     

    En cuanto a la capa de presentación (mas o menos lo que ha comentado Yeray):

     

    Yo descartaría XBAP, personalmente del modo que esta avanzando Silverlight, no le encuentro mucho sentido, además solo funciona en IExplorer con lo que para eso puedes usar una aplicación WPF directamente, incluso puedes hacer uso de activeX con Silverlight para características especiales como acceso a funciones del sistema, COM, hardware, etc.

     

    WPF: si requieres un acceso completo al sistema, esta es una buena opción, el “inconveniente” es que solo funciona sobre clientes Windows, pero se puede publicar la aplicación para acceder a ella de forma online, se pueden crear ventanas a medida, multimonitor, y en general lo que quieras en un entorno Windows.

     

    Silverlight: si requieres de una aplicación completamente distribuida, para clientes Windows, mac, Windows Phone, usada directamente desde un navegador (actualmente todos los habituales). El inconveniente es que no tienes acceso completo al sistema, pero simpre puedes incluir algún activeX para acceder al mismo (lo cual se estaría limitando a windows e IExplorer, y otros navegadores mediante un complemento en su lugar).

     


    Esto es a grandes rasgos, como hay que enfocar el proyecto, si te podemos ayudar en algo en concreto comentalo.

    ya contaras como te va.

     

     


    Saludos
    David González
    MCP, MCTS
    Visita mi Blog en: http://www.dgzornoza.com/
    martes, 22 de marzo de 2011 9:52
  • El problema de la asincronicidad al que me refería no es por Silverlight, sino por la propia naturaleza de una aplicación asíncrona. Y sin experiencia en escenarios asíncronos, esto va a ser un hueso duro de roer a tiempos.

    Por mucho que me guste Silverlight y hacia dónde se dirige como plataforma, algo que he aprendido a base de palos es a quitarme de vez en cuando el sombrero de programador y ponerme el de empresario, por aquello de cumplir los plazos. Y en este caso concreto, no dejo de preguntarme si no sería más rentable decidirse por WPF: aprovechando una primera iteración para adaptar la aplicación al .NET Framework 4.0, utilizar algún ORM para rediseñar el acceso a datos y empezar a jugar con el patrón MVVM y XAML. Y dejar el tema de Silverlight para una segunda o tercera iteración.

    En fin, mi argumento no era gratuito: está basado en mi experiencia los últimos 8 meses desarrollando una aplicación comercial con Silverlight 4 + WCF RIA Services sobre Windows Azure.

    martes, 22 de marzo de 2011 14:34
  • A ver... cadessi, para que la gente no se confunda:

    Mis argumentos tampoco son gratuitos, están basados en los ultimos 2 años usando Silverlight, WPF, WCF....

    Como puedes ver si visitas mi blog, en Silverlight 4 usas: .NET 4, y MVVM y XAML para la capa de presentación, y normalmente si es una aplicación un poco grande usarás servicios WCF como tu modelo para backend... tanto en WPF como Silverlight indistintamente.

    Esto que dices de dejar Silverlight para una segunda o tercera iteración es, de forma llana y directa, una burrada, porque convertir un proyecto entre WPF y Silverlight no es que sea trivial, además si ya lo tienes en WPF... para que vas a cambiar a Silverlight, y viceversa....

    No se como estas desarrollando en Silverlight, pero te puedo asegurar con conocimiento de causa que en Silverlight el desarrollo de una aplicación de negocio en capas, con WCF, Entity framework como DAL y MVVM como patrón de diseño de la capa de presentación es totalmente factible e igual de sencillo o complicado que en WPF.

    Un saludo!


    MCTS .NET Framework 3.5 Windows Forms Application Development
    MCTS .NET Framework 3.5 Windows Presentation Foundation
    Visita mi Blog en Geeks.ms
    Sigueme en Twitter
    martes, 22 de marzo de 2011 15:03
    Moderador