DB40. Persistencia nativa de las clases en c#
Si nos paramos a pensar dos de las grandes tecnología de desarrollo, .NET y J2EE, tienen como pilar fundamental, la orientación a objetos. Muchas de los entes, y demás cosillas, que nos encontramos en los frameworks de trabajo son objetos y existe un diseño orientado a objetos ( que en muchos casos cuesta más de un disgusto en la carrera). Incluso los más avanzados (arquitectos y otras criaturas del mundo del desarrollo) aplican diseño de patrones para manejar dichos objetos.
Es decir, tenemos un diseño O.O. digamos unas cuantas clases, que durante la ejecució de nuestro programa, se van a instanciar en objetos concretos, que contendrán y manipularan información, información que se perderá si no lo almacenamos en algún sitio. Normalmente, este sitio será la bbdd, y necesitaremos de un gestor de bbdd, que guardará la información en tablas, quizá siguiendo algún esquema del modelo relacional. Pero claro, nuestro objeto en memoria, a veces complejo, necesitará ir a filas concretas de tablas concretas.
Hemos oido que una capa de acceso a datos, una dll, con las funciones concretas para acceder a los datos podría ayudar a establecer un mapa, entre los objetos relacionales de la bbdd y los objetos del entorno de ejecución. Esta historia nos suena (funciones del tipo GetAmigo_by_Nombre(), que seguramente ejecutarán comandos de la bbdd, igual hasta sentencias sql,.... ). Ahora bien,...
Existen mecanismos que podrían reducir el gap que se produce entre las entidades que manejarían nuestro negocio y la información que almacenamos. El concepto es el de persistencia nativa. Hoy voy a recomendaros el motor DB40, http://www.db4o.com.
Ilustración 1. Desde db40.com
Db4O nos independiza del motor de bbdd, es en sí mismo un motor de bbdd, en realidad permite almacenar objetos de manera nativa:
ObjectContainer db = Db4o.openFile("ElFicheroAmigos.yap");
Amigo a = new Amigo("Pepe", "Calle la patata");
db.set(engine);
db.commit();
db.close();
Por supuesto, un amigo, puede tener una clase dirección, e incluso una lista de juegos preferidos. Todo sólo haciendo un simple using. Con un delegado podemos crear predicados así a pelo, y podremos recuperar amigos de esta manera.
IList<Student> students = db.Query<Student>(delegate(Amigo el_amigo){
return el_amigo.Age < 20
&& el_amigo.TieneAmigas;
}
);
Sí así recuperaríamos la lista de amigos de menos de 20 que tienen amigas, siempre que TieneAmigas sea de tipo bool claro. Toda una lista de objetos en un abrir y cerrar de ojos, ni linq, ni nada de nada. Más fácil parece imposible.
Aún quedan muchas cosas por descubrir sobre este motor, con el que ando trabajando. Claro siempre hay detractores, esto es experimental,… ya veremos el tiempo de programación que ahorra.