Un vistazo a linqToXsd

Bueno, para los que no esteis muy al tanto de esta tecnología de .NET, linq es un conjunto de tecnologías para el acceso a datos capaz de serializar tipos a fuentes de datos diversas, y deserializar en forma de tipos accesibles por el analizador sintáctico del lenguaje en cuestión (C# por ejemplo).

Esto es algo verdaderamente glorioso, pues mediente unas reglas sintácticas muy sencillas podemos acceder a los datos ya tipados y también serializarlos -almacenarlos de forma permanente- de manera tal que los errores de acceso a datos van a surgir, XD, en tiempo de diseño -en la compilación- y no en tiempo de ejecución, cuando ya no podemos cazarlos.

linqToXsd es una librería más de este conjunto que utiliza un archivo xml como origen de datos, pero que a diferencia de linqToXml, es capaz de utilizar un esquema de definición de datos asociado en forma de archivo xsd para generar internamente un conjunto de tipos que son añadidos automatizadamente a la blblioteca de tipos del proyecto y pueden ser manipulados en tiempo de diseño.

Las ventajas son evidentes: es posible entonces extraer listas de objetos directamente tan solo mediante una expresion lambda y un casting al tipo adecuado que ha sido generado desde el xsd. Casi ná…

Ejemplo:

Un usuario experto se plantea la necesidad de ejecutar muchas veces un grupo relativamente reducido de operaciones sobre un banco de imágenes: cambiar su título, su descripción, adscribirlas a categorías diferentes, eliminarlas…

Dado que por sus conocimientos controla Excel con un mínimo de dignidad, era posible la solución que se le propuso, que no fué otra que generar una hoja con datos tabulados en 3 columnas : identificador de la imagen, operación y valor, que queda en el sistema definiendo una interfaz común

public interface OperacionesConImagenes
{
void Do(ushort? idImagen, string valor);
}

y el cjto de operaciones como clases que la implementan

La parte más chula de todo esto es que tan sólo hay que convertir la hoja a XML y extraer la plantilla correspondiente:

<?xml version=”1.0″ encoding=”utf-8″?>
<xs:schema attributeFormDefault=”unqualified” elementFormDefault=”qualified” xmlns:xs=”http://www.w3.org/2001/XMLSchema”&gt;
<xs:element name=”ListaDeTareas”>
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs=”unbounded” name=”Tarea”>
<xs:complexType>
<xs:sequence>
<xs:element name=”Orden” type=”xs:unsignedShort” />
<xs:element minOccurs=”0″ name=”pg” type=”xs:unsignedByte” />
<xs:element minOccurs=”0″ name=”Id” type=”xs:unsignedShort” />
<xs:element minOccurs=”0″ name=”Nombre” type=”xs:string” />
<xs:element name=”Operacion” type=”xs:string” />
<xs:element minOccurs=”0″ name=”Valor” type=”xs:string” />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

la cual es utilizada por la librería para generar unos tipos en la biblioteca de objetos: el tipo ListaDeTareas y el tipo Tarea, siendo el primero una lista de objetos del segundo tipo. Para ello hay que aplicar el valor LinqToXSDSchema a la propiedad BuildAction del objeto xsd que hemos integrado en la solución.

Y así, desde el xml se pudo almacenar una lista de tareas en forma de tuplas Tareas que fueron ejecutadas. La forma de obtener la operación a aplicar con un parámetro de entrada de tipo string fué así:

OperacionesConImagenes opAplicar = Activator.CreateInstance(Type.GetType(“OperacionesEnBatch.Op” + Enum.GetName(typeof(TiposOperacionesConImagenes), operacion))) as OperacionesConImagenes;

opAplicar.Do(idImagen, valorOperacion);
Mola, eh?

Para saber más sobre el tema…

Advertisements

¿Se almacena la información independientemente del sistema?



Hola calamares.

Mis amigos-con la web 2.0 podría haber hecho un multienlace a todos ellos…- saben que desde hace tiempo me ronda por la cabeza esta idea. Y es que observo la evolución de los paradigmas de desarrollo del software y la hallo en extremo similar a la evolución del almacenamiento de información en los sistemas vivos -algo que conozco con el criterio de autoridad que me da mi título, pero que en realidad no es tanto como debiera-, o sea, la evolución del material genético en la filogenia.

Y es sorprendente hasta qué punto son parecidos: si asociamos los conceptos de programa/aplicación a los ácidos nucléicos (doble hélice de ADN o ARN), el progreso es paralelo: el cromosoma único bacteriano y la programación estructurada, el núcleo eucariota y la programación modular, o más el paradigma orientado a objetos con el encapsulamiento y el polimorfismo implementado con la presencia de la membrana celular y la funcionalidad alélica.

la evolución hacia la programación orientada a objetos es aún más patente al subir un nivel de funcionalidad -subimos una capa de abstracción en la máquina– y observamos la organización histológica -clases de células- y orgánicas -ensamblados o paquetes-…sin palabras.

En sí, una célula es análoga un objeto de la POO -instancia de una clase genérica o especie– cuya característica primordial es la de mantener un grado de autonomía funcional lo suficientemente importante como para poder ser reutilizado en una estructura dinámica de nivel superior u organismo -aplicación modular donde las haya…-. Almacena información encapsulada -o doblemente encapsulada si es una célula eucariota o nucleada-

Pues bien, barrunto que tamaña semejanza no puede ser fruto de la casualidad. ¿Y si la información, cuando crece, tiende a almacenarse en estructuras similares (homólogas dirían los biólogos, polimórficas los informáticos)? ¿Y si ES NECESARIO que la información se fragmente a partir de una cantidad crítica para poder asegurar la disponibilidad? ¿Y si para asegurar esa disponibilidad se hace imprescindible que esos fragmentos de almacenamiento se rodeen de estructuras y adquieran una funcionalidad mínima? ¿Y si, por último, fuese imprescindible para poder separar la funcionalidad “interna” de la que verdaderamente ofrece, el que se aislen del entorno, se encapsulen?

Contadme vuestras impresiones, que éste es un tema que verdaderamente me apasiona.