2011-01-31 12 views
8

Estamos planificando una aplicación que se desarrollará tanto en Silverlight como en WPF.Compatibilidad con Silverlight y WPF

Quería saber si, dado que se implementará la interfaz en XAML, ¿será compatible con ambas tecnologías?

¿Qué tipo de problemas deberíamos esperar al pasar de una tecnología a otra?

+2

duplicados de http://stackoverflow.com/questions/3626936/silverlight-4-and-wpf-compatibility y http://stackoverflow.com/questions/598703/definitive-sources-for-the-difference-between-silverlight-and-wpf –

+1

también dup de http://stackoverflow.com/questions/944608/ – SergioL

Respuesta

0

En última instancia Silverlight era/es sólo un subconjunto de la entidad WPF, por lo tanto, usted tenderá a encontrar algunos de los elementos disponibles en WPF ausente cuando la migración a Silverlight, tales cosas incluyen:

  • La falta de certeza de unión soporte en Silverlight.
  • Formas más finas para ajustar las propiedades de dependencia disponibles en WPF no presentes en Silverlight.
  • Los guiones gráficos se desencadenan en código usando Silverlight en lugar del Triggers de WPF.
  • WPF y Silverlight utilizan diferentes bibliotecas principales, lo que puede significar la imposibilidad de compartir bibliotecas entre aplicaciones WPF/Silverlight.
  • Hay menos controles incorporados disponibles en Silverlight en comparación con WPF.

Y así sucesivamente.

Conjeturo que con lo que terminará teniendo la mayoría de los problemas será el portar sus controles personalizados, que, como con muchos de los otros códigos, será transferible en gran medida pero tendrá un montón de advertencias aparentes entre tanto el mark-up como el código detrás. Probablemente tendrá que ajustar la mayoría de los controles WPF para compilar en Silverlight, alterando los valores TargetType para plantillas, recursos, etcétera, y reemplazando un control por otro (o algunas veces teniendo que crear uno propio para lograr un objetivo, un ejemplo de esto es el UniformGrid que falta en Silverlight)).

Publicaba enlaces, pero los otros tipos parecen haber expuesto todo lo que necesita saber acerca de las redes. Que te diviertas.

+0

Storyboards se pueden iniciar a través de transiciones visuales de estado en ambos marcos. ¿No sería esa la manera de hacerlo si estás apuntando a wpf y Silverlight? – Justice

+0

Probablemente tengas razón; Recién estoy recordando por la experiencia pasada de lo que se debe a que tuve que llamar manualmente a 'Storyboard.Begin', no encontré la alternativa que sugieres. –

2

He creado una aplicación dual dirigida de Silverlight/wpf. No es tan simple como trasladar uno a otro ...

Los primeros pasos deben ser ver la documentación sobre dónde difieren wpf y silverlight para comprender un poco mejor su problema XAML Processing Differences Between Silverlight and WPF. No te detengas allí. Comprenda los patrones de diseño que entran en juego en función de los diferentes entornos de aplicación. Ahora estás empezando a tener una idea de a lo que te enfrentas.

Al construir UI para wpf y silverlight, se debe tener mucho cuidado con los controles y los espacios de nombres en uso. Compartir el código de la interfaz de usuario puede ser extremadamente tedioso, a menudo es más fácil crear dos capas de interfaz de usuario separadas que usan plantillas compartidas donde sea aplicable. Gran parte de la funcionalidad de la interfaz de usuario que tiene en una aplicación cliente enriquecida va a diferir de la funcionalidad en su aplicación Silverlight. Probablemente ofrecerá vistas más intensas de datos enriquecidos en su aplicación wpf en lugar de vistas más concisas en su aplicación silverlight. Al final, probablemente podrá lograr los mismos objetivos, pero va a ser más difícil que solo reorientar e implementar.

Si está compilando una aplicación desde cero, entonces recomendaría construir la aplicación wpf y la aplicación Silverlight al mismo tiempo.Al hacer esto, se encontrará con oportunidades para abstraer capas de servicios y estrategias de acceso a datos utilizadas en los diferentes entornos. Silverlight probablemente necesite acceder a los datos a través de servicios web, mientras que su aplicación wpf podría hablar con una instancia de base de datos local. Esto se puede lograr con bastante facilidad. Use un contenedor IoC o algo para inyectar las implementaciones de servicio adecuadas. Esta área ofrece la oportunidad de reutilizar más código. Puede crear toda su lógica de vista y lógica de servicio para compartir entre las dos IU. También puede crear lógica comercial compartida y lógica de acceso a datos.

Si no va a tener un almacén de datos local en su aplicación de cliente enriquecido, entonces olvide el siguiente párrafo.

Si está planeando tener un cliente fuera de línea ocasionalmente conectado (aplicación wpf), probablemente tendrá que encontrar algún tipo de estrategia y arquitectura de sincronización. Dependiendo de cuán complicadas sean sus estructuras de datos, esto puede ser bastante difícil. Construir en lógica de sincronización compleja con marcos disponibles es una P.I.T.A. Puede que tengas que construir el tuyo propio o vivir con las restricciones de otro.

Una declaración del consejo: comenzar con las pruebas y terminar con las pruebas

Cuestiones relacionadas