[SilverLight] Implementando Servicios (I)

Actualmente ando liado haciendo mi primera aplicación web y mi primera aplicación SilverLight; ya que hago algo que sea a lo grande y a lo bestia para empezar en lugar de ir poco a poco…

En el caso que me ocupa ya publicaré la aplicación cuando esté terminada, pero dedicaré este artículo a hablar un poco sobre SilverLight y el modo en que se trabaja, que es ligeramente distinto si nunca has trabajado más allá de una aplicación de escritorio e incluso más allá de una aplicación ASP.NET.

En primer lugar, partimos de la base que SilverLight (en adelante SL) posee sus propias versiones de librerías y que los proyectos de SL son incompatibles con proyectos no-SL. Es decir, si deseas usar una librería para tu aplicación SL deberá ser una librería de SL, será imposible usar una librería de clases estándar. Como parte positiva de esta característica tan peculiar tenemos el bajo acoplamiento de la aplicación SL respecto a otros objetos, pero por contra obtenemos un modo de trabajo un tanto peculiar. En la aplicación que estoy desarrollando, además de la propia lógica que incluye empleo la serialización de entidades. El problema principal con el que he topado han sido los conflictos de DLL entre ASP y SL y que por motivos de seguridad, SL impide realizar cualquier acceso a disco.

Pero vayamos por partes: ¿podemos usar System.Xml.Serialize para serializar nuestras entidades como si de una aplicación de .NET normal se tratase? Evidentemente que sí, pero con el problema de que no podremos usar XmlSerializer para el proceso de seralización y no podemos usar los streams para acceder a disco. Para solucionar el tema del acceso a disco usaremos servicios web, pero para la serialización algunas de las soluciones que he visto por los foros se basan en:

• No podemos usar XmlSerializer: No pasa nada, implementamos una función que lea el fichero y en función de los nodos y etiquetas asigne los valores correspondientes. Incoveniente: no es genérico; para cada tipo de entidad hay que readaptar la función para obtener los nodos correspondientes. O bien se implementa un propio XmlSerialize para SL que sea genérico.
• Problemas de DLL’s: El hecho de usar XmlSerialize implicará conflictos de DLL’s entre las entidades a serializar de lógica de SL y la DLL del servicio web. Algunas de las soluciones se basan en copiar la DLL que falta a mano e incluso en añadir una clave al GAC (Global Assembly Cache) con la referencia de la DLL solicitada. Esta última solución me parece un absoluto hecatombe para la sensibilidad humana, por le siguiente escenario: Supongamos que cojo mi aplicación y la subo a un hosting. Es evidente que en el hosting tendré los permisos de administrador supremo para realizar esas tareas, y si así fuera, no hay nada mejor que una aplicación mantenible que requiere de la pericia de copiar y pegar DLL’s no soportadas por el Framework estándar para que nuestra aplicación pueda ejecutarse correctamente.

Entonces, si no podemos usar XmlSerializer pero queremos serializar para comunicarnos con nuestra lógica y acceder a disco, ¿qué podemos usar? Pues el maravilloso Windows Communication Foundation, que es una API orientada a proporcionar comunicación entre todos los servicios y aplicaciones desarrolladas con .NET. En el próximo artículo expondré un artículo práctico sobre cómo WCF con SL.