Generic Data Access Layer

[jocks]

Hola gente!!!
Bueno en mi proyecto actual se me presenta el reto de que la aplicacion debe de adaprtarse a cualquier manejador de datos,pasa q la empresa q usara la app actualmente usa DBFs pero tiene planeado migrar a otro motor de datos.
Estuve googleando y encontre que puedo usar el patron abstract factory aplicado en la construccion de "un componente generico de acceso a datos" , ok hasta ally todo bien , pero tengo 2 dudas :

1. .NET para conectarse a ORACLE y MySQL por ejemplo necesita tener instalado el "driver" de conexion de cada base de datos respectivamente, como manejo esto? si los usuarios que manejaran la aplicacion solo deben de decirle a la aplicacion que estan manejando tal motor de datos, definir la cadena de conexion y nada mas.Como manejo este detalle dinamicamente??
2. El tema de los stores procedures(SP) . Como manejo los SPs? Es decir, si es un componente generico no puedo definir SPs para un motor especifico, o es que en este caso no puedo trabajar con SPs y tan solo con queries directos desde codigo .NET?

Bueno espero que alguien haya pasado por algo parecido antes y me pueda aclarar esto.

Saludos

[javiermil]

Hola, referente a la primera pregunta, que quieres que el usuario elija el tipo de base de datos? O que sepuede migrar facilmente de base de datos sin apenas cambios en la aplicación?

Saludos

[jocks]

ok! te describo el escenario.
La aplicacion web asp.net 1.1 debe ser totalmente independiente del motor de base de datos que se utilize.
Estuve investigando y me encontre con los OR MAPPERS (mapeadores de objetos) en este caso con el Lattice.DataMapper, el cual al parecer por lo que he visto hasta ahora me puede ayudar mucho a trabajar esto.

Bueno obviamente no se usaran stores procedures ni funciones, todo sera sql puro.

El proceso sera el siguiente:

1. El usuario levanta la app y se el muestra una ventanas iniciales de configuracion.
2. Usuario indica el motor de datos(db2,oracle,etc) y la cadena de conexion para poder conectarse a la base de datos
   Esto se almacena en un archivo XML
3. El usuario indica los nombres de las tablas y los nombres de cada campo.
   Esto se almacena en un archivo XML
4. Con toda esa informacion recopilada la applicacion ya tiene los datos necesarios para poder adaptarse al motor de datos que sea.

Solo para aclarar el punto 3,se da porque el usuario de la aplicacion al realizar el proceso de migracion de su Base de Datos (actualmente archivos DBFs) podria cambiar el nombre de las tablas y campos,es por ello que la aplicacion necesita saber esos nombres para poder trabajar las consultas o actualizaciones.

Alguna recomendacion de lo que describi???

[javiermil]

Hola, lo único que se me ocurre es que hagas una libreria de clases por cada bd eso concretaría el acceso a cada bd, por otro lado haces una generica que accede a los metodos de esas clases que tendrán el mismo nombre. Con el xml que dices pues ya seleccionarias a que clase te referenciarias. Yo trabajo con distintas librerias, tengo una por cada BD pero las llamadas son iguales. Solo tengo que cambiar la libreria de acceso a bd, en tu caso, tienes que tenerlas todas y referirte a una u otra dependiendo de lo que elija el usuario pues lo haces con la generica, en esa generica importas cada una de las librerias y dependiendo de los parametros que se te pasen elegirias una. Espero que te sirva de ayuda. Saludos

[jocks]

habia pensado algo como lo q describes!
pero no t parece q no es una muy buena practica de programacion el definir una libreria para cada base de datos?? se estaria violando el concepto de interfaces y POO.

Q opinas?

[javiermil]

Bueno, ten en cuenta que la clase generica es como una clase abstracta, cada clase especifica de cada BD es una clase que hereda de esa, así que lo de que viola los conceptos de interfase y POO, no lo veo así, además te es necesario ya que las funciones para cada BD son distintas y algunas especificas,c omo lo que comentabas de los procedimientos almacenados. Además, ten en cuenta, que la aparicion de una nueva BD en tu listado de BD's sólo seria añadir una clase. Yo creo que más transparente no puede ser. Lo mismo hay soluciones mejores, pero desde luego yo trabajo así. Saludos

[jocks]

Entonces lo q propones es algo como lo siguiente :
*Consideremos ORACLE, SQL SERVER y MYSQL como los posibles escenarios(recalco que solo son supuestos).
En base a ello yo tendria q implementar 3 librerias (uno para cada uno):
-ORACLE trabajar con objetos oracleconnection, oraclecommand,etc....
-SQL SERVER trabajar con objetos sqlconnection,sqlcommand,sqldatareader,etc...
-MYSQL trabajar con objetos oledbconnection,oledbcommand , etc....

Y solo faltaria trabajar con objetos odbc q no son muy usados en realidad.

Entonces solo serian 4 librerias, no existen mas , ya que son los unicos que .NET ofrece.
Corrigeme si me equivoco.

Otra detalle es que como dije antes "el motor d base de datos debe de ser totalmente transparente para la aplicacion" lo q implica si se migra la base de datos a otro motor d datos, "no se debe recompilar la aplicacion, sino adaptarse dinamicamente de acuerdo a lo que se especifique en los archivos XML"

q opinas?

[jocks]

Lo que me sugieres es algo como esto ??

http://www.dotnetheaven.com/Uploadfi...rypattern.aspx

Saludos

[javiermil]

Hola, bueno la verdad es que como en tu caso, el usuario elige la base de datos, es decir, tienes que tener en el proyecto las 3 o 4 librerías pertenecientes a cada BD tienes que tener algo que marque a cual de ellas referirte, por lo que una clase abstracta no podrías implementar, sería una clase la cual llamaría a los metodos de las otras 3 dependiendo de a qué base de datos eligiese el usuario, es decir, un parámetro que tienes que pasarle es el tipo de base de datos, para después elegir uno de los métodos de una de las 3 o 4 librerías. Yo desde luego, es la forma que veo, porque hacerlo más genérico no veo cómo. De todos modos, añadir una librería( de otra BD) sólo supondría meter esa librería y hacer pequeños cambios en la clase que llamaría a las demás. Bueno espero haberme explicado bien, saludos y suerte con el proyecto.