Pasar de WPF a Silverlight: ¿Cuáles son las principales diferencias?

Question

He hecho un proyecto completo usando WPF, y tengo (al menos) una buena comprensión de los conceptos principales, como XAML, Databinding y MVVM. Hicimos todo "a mano": no usamos un marco de MVVM ni herramientas de terceros. Todo el XAML fue escrito a mano también (sin mezcla).

El nuevo proyecto que comenzaré en unas pocas semanas es Silverlight de trabajo pesado, y estoy buscando ponerme al día lo más rápido posible. Sin embargo, la mayoría de los artículos que he leído sobre cómo comenzar con SL se centran en XAML y en el enlace de datos. Dado que mi introducción a estos conceptos todavía está muy fresca en mi memoria, ciertamente puedo entender por qué estos tutoriales dedicarían mucho tiempo a estos temas: la curva de aprendizaje puede ser muy pronunciada. Sin embargo, estos son conceptos con los que ya estoy familiarizado, y me veo obligado a recorrer una gran cantidad de terreno cubierto para aprender algo nuevo y convincente.

Así que lo que estoy buscando son consejos sobre lo que necesito aprender y entender para pasar de ser un WPF'er oficial a un oficial Silverlight'er. Esto puede ser en forma de:

• Consejo general
• Principales diferencias
• Reglas generales
• Recursos/Enlaces ("Guía del WPFer a Silverlight" sería perfecto :)
• Principales trampas/Cosas a tener en cuenta

Gracias de antemano por cualquier idea.

Answer 1

Rob Eisenberg (creador de Caliburn y Caliburn Micro) tiene una serie de publicaciones en el blog que habla acerca de cómo portar una aplicación WPF a Silverlight. Esto puede darle una idea de algunas de las diferencias de framework.

Día 1 http://devlicio.us/blogs/rob_eisenberg/archive/2010/03/25/porting-nhprof-from-wpf-to-silverlight-day-1.aspx

Día 2 http://devlicio.us/blogs/rob_eisenberg/archive/2010/03/29/porting-nhprof-from-wpf-to-silverlight-day-2.aspx

Día 3 http://devlicio.us/blogs/rob_eisenberg/archive/2010/03/31/porting-nhprof-from-wpf-to-silverlight-day-3.aspx

Día 4 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/01/porting-nhprof-from-wpf-to-silverlight-day-4.aspx

Día 5 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-5.aspx

Día 6 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-6.aspx

Día 7 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-7.aspx

Día 8 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-8.aspx

Algunos otros pensamientos de la parte superior de mi cabeza:

• defecto unión a un solo sentido
• Sin DynamicResource
• TabControl es bastante diferente
• Sin posibilidad de definir implícita DataTemplate s para este tipo de
• Sin CoerceValue en las propiedades de dependencia
• enrutamiento de eventos es muy básico
• no está integrado en la estructura de mando. Usted tiene la interfaz ICommand, y los controles ButtonBase tienen una propiedad Command, aunque no existe una clase que implemente la interfaz ICommand.
• Falta x: estático, x: tipo
• Todas las llamadas de servicio deben estar en un subproceso diferente del subproceso de la interfaz de usuario. Esto esencialmente requiere que aprendas/implementes estrategias de programación asincrónica. Ver here y here.
• Como se mencionó, es un marco diferente, por lo que no todas las bibliotecas están disponibles para usted. Ejemplo: no hay XmlDocument: debe usar XElement (que es posiblemente mejor, aunque así)
• El marco de navegación es totalmente diferente de WPF. Mantente alejado de eso. Solo te causará dolor. ;]
• Varios de los controles que encontrará en el marco central en WPF encontrará en el Silverlight Toolkit. Descárguelo, lo necesitará.
• Sin desencadenantes incorporados, aunque puede utilizar comportamientos/acciones proporcionadas en el SDK de mezcla (que esencialmente le ofrece lo mismo)
• Si necesita interactuar con una base de datos, tendrá que ser a través de servicios alojados en algún lugar , o a través de COM (lo que significa Silverlight 4 OOB con permisos elevados).
• No estoy de acuerdo con Kevin en que las pruebas son bastante fáciles y todos los principales frameworks de pruebas y frameworks burladores son compatibles con Silverlight. Donde se encuentra con problemas es la cobertura del código. El marco de prueba de Microsoft admite cobertura de código (Premium & arriba) o bien puede usar dotCover. Creo que las versiones más nuevas de nCover son compatibles con Silverlight, aunque no estoy 100% seguro. Use StatLight para ejecutar sus pruebas de Silverlight (independientemente del marco de prueba) desde la línea de comandos.
• Si aún no está utilizando un contenedor de IoC, elija uno. Autofac, Ninject, StructureMap, Unidad, MEF.(Otra parcialidad mía;])

Sugeriría mucho buscar en los marcos de MVVM disponibles. Esto ha reducido una parte importante del código de marco que normalmente tengo que escribir. Los marcos probablemente solo le darán el 80% de lo que necesita, aunque eso es 80%, no tiene que escribir usted mismo. Actualmente soy partidario de Caliburn Micro, aunque la mayoría de los populares le darán lo que necesita.

Agregaré más si pienso en más. ¡Buena suerte en su viaje!

Answer 2

Realmente solo he hecho de Silverlight una aplicación real ... pero uno de mis compañeros de trabajo era un gran tipo WPF, y por eso escucho algunas de sus quejas.

• Vas a probable que tenga que utilizar un servicio WCF, etc., para consultas asíncronas a la capa de servicio/negocio
• Estás usando un subconjunto de la plataforma .NET, por lo que no se puede incluir CUALQUIERA de sus bibliotecas de clase como referencia, solo se pueden incluir bibliotecas de clases Silverlight. Sin embargo, puede hacer cosas como tener un 'enlace al archivo existente' en una biblioteca Silverlight que se vincula a un archivo en otras bibliotecas ... siempre y cuando el código se compile solo con el conjunto reducido. Esto es un poco una pesadilla de mantenimiento, pero si está haciendo WPF & Silverlight con parte del mismo código, probablemente le ahorrará mucha replicación. Asegúrese de hacer un enlace al archivo y no una copia del archivo, o los cambios en uno no cambiarán el otro.
• La prueba de la unidad de su ViewModels no será tan fácil. Necesita Moq su servicio y utilizar un proyecto de prueba de la unidad de Silverlight.
• Algunas de las funcionalidades reducidas son molestas para los veteranos de WPF.
• Creo que nuestro tipo WPF se quejó de no ser capaz de enlazar cosas como un método CanExecute tan fácilmente en sus comandos como lo pudo hacer en WPF. Tenía que llamar al método directamente desde el comando o algo así. (Sólo he tenido la oportunidad de mirar a MVVM un poco para lo que a mí ahora en un proyecto diferente :(, así que no está muy seguro de que uno).

Espero que ayude un poco.