2010-01-10 24 views
5

Acabamos de pasar por una pequeña sesión de experimentación para tratar de ver cuánto trabajo llevaría nuestra biblioteca de clases .NET, o al menos partes de ella, a Silverlight para que podamos reutilizar la lógica de negocios entre los dos mundos, Me pregunto si otros tienen experiencia con este tipo de cosas.¿Viabilidad de código compartido entre .NET y Silverlight?

Las cosas me di cuenta, de la parte superior de mi cabeza:

  • Un montón de atributos que faltan (navegables (falso), por ejemplo)
  • Las porciones de la falta de interfaces, o presentes, pero vacías (ICloneable es oculto, ITypedList falta)
  • diferencias de reflexión (necesidades alcanzables que todo sea público)
  • Algunas diferencias de clase de base (sin componente?)

Entonces, me pregunto, ¿es realmente posible para mí considerar esto como una posibilidad?

Obtuve el código inicial en ejecución, pero solo tuve que comentar una gran parte de la funcionalidad básica, sobre todo en las listas de manejo ya que están basadas en ITypedList y algunas clases base. Aparentemente tengo que cambiar a ObservableCollection en Silverlight, por lo que es necesario cambiar todo el código base para poder enfrentarlo.

La clase real de prueba de negocios que he creado es 99.5% idéntica a la que habría hecho para .NET, solo algunos cambios menores que también se podrían usar fácilmente en .NET, simplemente no como lo hubiera hecho antes de mirar a Silverlight. En otras palabras, parece factible compartir la lógica comercial, siempre que pueda compatibilizar las clases base.

Así que estoy claro, lo que estoy diciendo es que básicamente tendría dos archivos de proyecto, uno para .NET y otro para Silverlight, pero el código fuente de C# sería el mismo, compartido entre los dos.

¿Alguien tiene alguna experiencia con esto? ¿Algún consejo o guía?

¿Valdrá la pena? Ciertamente merece más atención.

Respuesta

4

Es definitivamente factible.

Se hace en un proyecto aquí; el proyecto Silverlight incluye los C#, y hay algunas declaraciones #IF que manejan algunas cosas (como declaraciones log4net), y otras veces las cosas simplemente se vuelven a implementar. Pero en general, es una gran victoria, y definitivamente debes intentarlo (y ciertamente, lo hemos logrado, con éxito).

- Editar:

Un punto, sin embargo, es que nuestro O/M (LLBLGen) no tiene soporte incorporado para objetos simples '' para enviar a través de Silverlight; pero alguien había escrito un complemento que lo manejaba, lo que ayudó. Por lo tanto, puede valer la pena considerar qué tipo de DAL está utilizando y qué tan bien admite Silverlight.

+0

Ok, bien, entonces no has encontrado ningún problema insuperable, supongo. Es bueno saberlo, entonces ciertamente seguiré adelante con este proyecto. –

+0

Lasse: Definitivamente faltan algunas cosas; No puedo recordar desde lo alto de mi cabeza, sino algunas cosas de Reflection, log4net, etc.Pero es definitivamente superable; (aunque, en VS2008 al menos, hay algunas cosas 'extrañas' a veces, cuando usas 'Agregar como enlace' para agregar una clase existente del proyecto principal y cambiarla, tienes que abrirla (de hecho abrirla) a través de el proyecto de Silverlight antes de que reconozca los cambios). Sin embargo, no hay problemas que destruyan el alma :) –

+0

Bueno. Lo que parece ser el mayor problema es que tengo que volver a implementar la base para nuestras clases de lista, ya que utilizamos listas mucho a través de nuestra lógica comercial, y tenemos algunas clases de lista especial que saben que están en un "mundo de lógica de negocios" ", pero al observar cómo se usa ObservableCollection, parece que hará lo que necesitamos, solo tiene que cambiar el código para lidiar con él. Nuestro contenedor de IoC funcionaba menos la configuración de app.config, pero de todos modos no la usaremos. Solo me preguntaba si alguien más había encontrado campos de minas que no podía ver de inmediato. –

4

Lo que he hecho para facilitar esto es:

  1. El uso frecuente de las clases parciales y #if SILVERLIGHT de separar el código en partes que Silverlight puede manejar.
  2. Uso de la generación de código siempre que sea posible.Por ejemplo, he estado experimentando con plantillas T4 que generan atributos equivalentes de Silverlight (DisplayAttribute en lugar de DescriptionAttribute, por ejemplo)
  3. Siempre que haya una interfaz/atributo no implementado por Silverlight (como IDeserializationCallback, ICloneable, INotifyPropertyChanging) lo haré crear una interfaz ficticia del mismo nombre en la aplicación Silverlight, siempre que sepa que el hecho de que la implementación no se utilizará no es un problema.
  4. Finalmente, vale la pena señalar que en Silverlight 4, el formato de ensamblaje permite compartir binarios entre Silverlight y .NET, siempre que no haya dependencias que Silverlight no admita.

Una nota más sobre la base de clases separadas - puede ser útil para crear una clase abstracta que se deriva de ObservableCollection en Silverlight y BindingList (o lo que sea que está utilizando en .NET) para minimizar el impacto en su mecanografiada colecciones.

ACTUALIZACIÓN Hoy en día yo estaba trabajando en portar algún código .NET para Silverlight que hace un uso intensivo de las API de System.Diagnostics como TraceSource, SourceSwitch, etc, que no existen en Silverlight. Creé implementaciones muy mínimas de estos en el proyecto de Silverlight y los puse en el espacio de nombres de Einstein.Diagnostics. Al hacerlo, decidí que necesitaba una convención para identificar fácilmente el código que imitaba el .NET Framework frente a mi propio código. Así que cambié el nombre de los archivos de marcador de posición para agregarles un signo @. También prefijé los nombres de clase en esos archivos también. Lo bueno de eso es que el signo @ en realidad no cambia sus nombres de clase en lo que respecta al compilador C#. Entonces @SourceSwitch todavía compila para ser Einstein.Diagnostics.SourceSwitch pero en el código puedo ver fácilmente que algo está activo. También decoré estas clases con un atributo [SilverlightPlaceholder].

+0

Definitivamente revisaré la dependencia de ObservableCollection en una clase base. Es bueno saber sobre Silverlight 4, pero desafortunadamente, probablemente no podamos saltar de inmediato. A excepción de ITypedList, no creo que ninguna de las interfaces que encontré plantee un problema. En cuanto a nuestras clases de lógica de negocios, ya están construidas usando un generador de código, aunque es nuestra propia herramienta, por lo que cualquier cosa que necesitemos que se solucione para obtener una compatibilidad del 100% se logra fácilmente. ¡Gracias por tu contribución! Solo entre las dos respuestas que obtuve ya estoy lo suficientemente aliviado como para seguir adelante con una actualización inicial. –

2

lo hago con protobuf-net, y utilizo algunos enfoques:

  • símbolos de compilación condicional en el archivo del proyecto de código para activar sutiles-ramas (sí, no es perfecto, pero funciona)
  • reintroducción de algunas cosas; los atributos pueden ser un ejemplo aquí - su código aún puede usar atributos reintroducidos, incluso si el código de la estructura no lo hace; como un ejemplo más extremo de esta, para un marco compacto que tenía que volver a introducir una buena parte de la API Expression, que fue muy divertido
  • simplemente deje caer algunas cosas ;-P

Sin embargo si usted es usando ITypedList (que mencionas), puedo ver que todo el enfoque se deshace bastante desordenado; El componente-modelo ya es lo suficientemente complejo, sin tener que abrirse camino a través de los hacks también. Realmente depende de lo lejos que hayas pasado por este camino. Tal vez 4.0/dynamic abrirá algunas de estas opciones nuevamente?

+0

Actualmente utilizamos ITypedList porque nos dio la capacidad de enlazar fácilmente a la mayoría de los componentes de la grilla en uso, con soporte para sub-propiedades. Es decir, puedo enlazar con "Employee.FirstName", donde Employee es una propiedad de los objetos en la lista. Todavía no sé si esto es posible con ObservableCollection, pero si lo es, nos ocuparemos de los cambios. –

+0

Y la biblioteca de la clase contiene toneladas de cosas que probablemente no van a necesitar, y usaremos la compilación condicional para muchas cosas también. Por ejemplo, una clase Heap que tengo, que utilizo, implementa las interfaces de colección no genéricas como IList e ICollection, que noté que estaba ausente en Silverlight, así que simplemente ignoraremos esas partes de Silverlight con algunos # if's bien ubicados . –

+0

En realidad, en Silverlight, la historia del enlace de datos es mucho más flexible que Windows Forms, por lo que el escenario que describió (enlace a sub-propiedades) no requerirá que salte por aros como ITypedList. Eche un vistazo a la sintaxis de enlace de la ruta de la propiedad y verá lo que quiero decir: http://msdn.microsoft.com/en-us/library/cc645024(VS.95).aspx – Josh

2

Una posible solución a su problema es copiar el código faltante del proyecto Mono. De vuelta en el día, hice un pequeño proyecto con Compact Framework y me faltaba todo el espacio de nombres de System.XLM. Acabo de copiar todo de Mono en mi proyecto, lo compilé y funcionó muy bien con cambios mínimos, iirc.

Cuestiones relacionadas