Espacio de Dario Quintana

Para quien no están familiarizado con NHibernate Validator: es un buen framework para validar objetos en cualquier parte de nuestra aplicación.

Ahora, como podemos integrar esta herramienta para poder validar nuestros objetos antes de almacenar un objeto en Db4o? La respuesta es fácil.

Recordemos que NHibernate Validator puede configurarse para validar usando .Net Attributes o archivos Xml. En este caso veremos como hacerlo usando la primer aproximación. La clase Customer debería lucir así:

Ahora para hacer la integración, llamaremos a un helper que haga el trabajo por nosotros. Nuestro código luciría así:

Como puedes ver, con una simple clase ayudante podemos configurar la integración con una línea de código, algo muy fácil. En esta línea el método Initialize registra los eventos en Db4o.

Ahora, vayamos a ver la Validación en Acción. El código de abajo muestra a la aplicación intentando guardar una instancia inválida de un objeto:

Entonces cuando un Save/Update está a punto de ocurrir, primero que nada, NHibernate Validator chequeará si la entidad se encuentra dentro un estado válido, sino lo está, una InvalidStateException será lanzada, entonces Db4o encapsula esta excepción con una excepción EventException, que luego deberemos atrapar y desencapsular para recuperar la primera excepción, y de esta manera obtenemos los valores inválidos que de la entidad. Sería bueno que Db4o no encapsule la excepción pero por varios motivos esto no puede ser así, esto fue discutido en el foro de Desarrollo de Db4o aquí.

Entonces, fue fácil integrar NHV con Db4o. No ?

Descargar el ejemplo

yaml es un lenguaje de serialización de datos, una alternativa al lenguaje de marcado XML. Es muy interesante, y es muy útil usarlo por que es más legible para el ojo humano que un archivo XML. Está enfocado a la simplicidad. Vamos a ver un ejemplo tomado de la realidad, así es como luciría un archivo de mapeo de NHibernate si fuera escrito en yaml:

Si usas NHiberante, debes darte cuenta que esto es mucho más fácil de leer. Como se puede apreciar la delimitación es hecha por identación. Si conoces lenguajes como Python esto te resultará muy familiar. Por supuesto, esto no está soportado en NHibernate, pero quien sabe, quizás alguien quiere donar algunas horas al OSS y hacerlo

Quizás una notoria desventaja es que yaml no posee esquema (schema). Y podés darte cuenta de las características que nos estamos perdiendo por esto, la más importante: validación de un documento yaml.

En .Net-landia no es tan popular, de hecho no lo es, pero en lenguajes como Python, Php, Perl, C++ se usa mucho. En el nuevo bebé de Google: Google App Engine, el cual tiene como lenguaje principal a Python (actualmente es el único lenguaje que soporta), usa yaml para los archivos de configuración.

Una de las cosas que me llama notablemente la atención, es la imposibilidad de poder configurar Db4o por medio de Xml, siendo algo tan común hoy en día y por sobre todo naciendo en Java.

La respuesta del lado de Java está justificada, no así del todo del lado de .Net. En Java, yo creo que la mayoría de los que usan Db4o usan el módulo de Spring para poder configurarla y obviamente no solo para eso, para usar las ventajas de IoC y Aop que posee Spring.

Algo básico que permite el módulo de Spring para Db4o es la capacidad de envolver a métodos que uno seleccione (y configure correctamente) en transacciones, de modo de abstraernos de este aspecto a nosotros.

Por que digo que no está tan justificado del lado de .Net, por que Spring del lado de .Net no es tan aceptado como lo es del lado de Java, que es donde nació. Y entonces mucho menos será entonces la adopción de dicho módulo pero para .Net.

Que lindo sería si se podría configurar Db4o de esta manera: 

<?xml version=”1.0″ encoding=”utf-8″ ?>
<db4o assembly=”db4oif.Test” namespace=”db4oif.Test.Objects”>
    <class name=”Customer”>
        <field name=”_id” unique=”true” indexed=”true”/>
    </class>

    <class name=”Product”>
        <field name=”_name” unique=”true” indexed=”true”/>
    </class>

    <class name=”db4oif.Test.Objects, db4oif.Test”>
        <field name=”_name” unique=”true” indexed=”true”/>
    </class>
</db4o>

Cualquier semejanza con un mapping file de NHibernate es pura coincidencia

Esto lo había expuesto aquí en el foro de la comunidad de Db4o, algún día espero tomarme el tiempo para escribir las clases de configuración, pero supongo que terminaré usando el módulo Spring que ya lo hace por mí (entre otras cosas).

Me nombraron dVP 2008, así que quiero agradecer a Db4o y su comunidad. Esta es la lista de los dVP 2008.

El bueno de Germán Viscuso me acaba de avisar que mencionaron adb4o analyzer en el db4o newsletter de junio en la parte de projects, que buena noticia.

Hace algún tiempo había hecho un ejemplo usando Spring y Db4o. Así se me pasó blogguearlo. Para los que quieren bajarlo está:

SalesDb4oSpring - v0.0.1.zip , Ã³

VentasDb4oSpring - v0.0.1.zip.

En la capa de acceso a datos tenemos:

• ClienteRepositorio
• RepositorioBase

En la capa de negocio tenemos:

• Cliente 
• ClienteBizComponent 
• BaseBizComponent

Por ahora la capa de presentación está hecha en una consola. Pero despues haré algún ejemplo más complejo, quizás con bindeo de objetos y winforms.

Estuve mirando en Db4o Analyzer y Object Manager la forma en que muestran las collecciones:

En Object Manager:

y en db4o Analyzer:

El problema está en que si un campo es una collección, muestra el tipo de dato de la collección. No muy útil por parte ambos.

Object Manager tampoco muestra el valor del Guid en el campo Id, esto creo que puede corregirse sin mucho código.

Voy a tratar de corregir esto de las collecciones en Db4o Analyzer, algo más a la lista del TODO.

En estos días estuve un poco ocupado para continuar agregandole features db4oanalyzer, pero si estuve haciendo un poco de refactoring. Aún quedán muchas cosas por hacer.

Estuve escribiendo algunas lineas para un parser para assemblies, de modo de poder crear funciones especializadas para trabajar con nuestras clases dentro de db4oanalyzer, quizás algún día se pueda realizar algún Query Maker a partir de una interfaz gráfica amigable y que genere el código para nosotros. Para el parseo del assembly estoy usando Mono.Cecil, un aplauso para JB Evain por esta librería !!! Inspeccionar assemblies con esta librería es facil, aparte de poder generar assemblies del formato ECMA CIL. Héchenle un vistazo aquí:

http://www.mono-project.com/Cecil

o aquí van a encontrar post sobre Cecil:

http://evain.net/blog/articles/category/cecil

Entre las otras cosas que pude hacer es mejorar el look-and-feel del árbol de objetos:

Para poder usar referencias de nuestras clases, entidades quizás, en Db4oAnalyzer, por ahora solo lo podemos hacer utilizando el archivo de configuración de la aplicación Db4oAnalyzer.exe.config.

<?xml version=”1.0″ encoding=”utf-8″ ?>
<configuration>

    <configSections>
        <section name=”db4oanalyzer” type=”Db4oAnalyzer.Core.Cfg.Db4oAnalyzerSection, Db4oAnalyzer” />
    </configSections>

    <db4oanalyzer>
        <references>

            <add name=”System” framework=”true” />
            <add name=”System.Data” framework=”true” />
            <add name=”Db4objects.Db4o.dll” />

            <add name=”E:\Assemblies\Entities.dll” />

        </references>
    </db4oanalyzer>

</configuration>

 El path del assembly con nuestras entidades de negocio (”Entitties.dll”) lo hemos puesto al final de los otros assemblies. Las entidades que corresponden al framework son marcadas: framework=”true”, el default es false.

Por ahora, estas referencias deben ser configuradas antes de iniciar la aplicación. 

Comenzé este pequeño proyecto Db4o Analyzer para facilitar el modo de probar nuestras consultas con db4o, escribiendolas desde una “snippet” IDE.

Por ahora, está soportando a C# como único lenguaje, pero la idea es extenderlo hacia otros. Tiene resaltado de Sintaxis e autocompletado de código, y esto gracias a las librerias opensource que se encuentran como parte del Core de SharpDevelop. De hecho esta herramienta fue escrita en dicha IDE.

La idea básica es ir agregando comando para poder visualizar mejor los objetos retornados, por ahora, podemos hacer esto:

draw<Persona>(db.Query<Persona>());

y con esto se realizará el query hasta la base, y podremos obtener en un arbol la consulta:

 Con este mismo enfoque podemos hacer nuestras queries, inclusive pobrar nuestras Native Queries.

ToDo (Cosas por hacer):

• Soportar VB proximamente.
• Permitir referenciar otras assemblies sin reiniciar la IDE.
• Modulo de Configuración de la Aplicación.
• refactoring !