2009-06-28 12 views
13

Tengo que diseñar una capa de acceso a datos con .NET que probablemente utilizará más de un sistema de gestión de bases de datos (servidor Mysql y Sql) con el mismo diseño relacional.Patrones de diseño de capa de acceso a datos

Básicamente, tiene que ser simple cambiar de una base de datos a otra, así que me gustaría que me recomendara algunos sitios web o libros que le hayan sido útiles, con patrones de diseño comunes o información en general para implementar esto. tipo de capa de acceso a datos.

Gracias.

Respuesta

12

recomiendo Patrones de Arquitectura de Aplicaciones Empresariales por Martin Fowler.

una lista de los patrones es también en su website

DataMapper El patrón también es relevante.

+0

¡Actualmente estoy leyendo este libro y puedo recomendarlo de todo corazón! ¡es genial! +1 –

0

He encontrado ADO.NET para ser muy útil para esto. Tiene todas las características que necesita para crear una capa de acceso a datos independiente de la base de datos que utiliza.

0

NHibernate está diseñado para manejar este tipo de escenario, si usted está dispuesto a aprenderlo

+0

La clase de DataSet estándar también maneja este tipo de escenario, ¿no es así? –

+0

sí, tiene razón, pero NHibernate le ofrece un mayor nivel de abstracción (por ejemplo, ya no escribe SQL pero utiliza el lenguaje de consulta interna creado por NHibernate o LINC cuando esté disponible) y facilita un poco transferir su modelo de datos a otro motor de base de datos. – oscarkuo

2

La solución más fácil sería usar un ORM. Consulte LLBLGen. Usando el Modelo de Adaptador puede cambiar entre proveedores de datos mientras usa los mismos objetos comerciales. Puede generar código para MySql y Sql Server.

+0

@Bob: un ORM es agradable, pero su pregunta no requiere una; solo para cambiar bases de datos Cualquiera de las tecnologías ADO.NET lo hará por él. –

+0

AFAIK ADO.NEt no resolverá las diferencias entre pl/SQL y TSQL, por ejemplo, ¿sí? Un buen ORM proporcionará la abstracción y hará la parte SQL por usted. –

8

Me gusta usar el acceso basado en interfaz Db. Cada proveedor de DB para Ado.net implementa las interfaces básicas, y cuando los utiliza su código puede tener este aspecto:

public static IDbConnection GetConnection(string connectionName) 
{ 
    ConnectionStringSettings ConnectString = ConfigurationManager.ConnectionStrings[connectionName]; 
    DbProviderFactory Factory = DbProviderFactories.GetFactory(ConnectString.ProviderName); 
    IDbConnection Connection = Factory.CreateConnection(); 
    Connection.ConnectionString = ConnectString.ConnectionString; 
    return Connection; 
} 

Entonces, cuando se necesita para comunicarse con db:

public static DataTable Dummy() 
{ 
    using (IDbConnection Connection = GetConnection("SiteSqlServer")) 
    { 
    IDbCommand Command = Connection.CreateCommand(); 
    Command.CommandText = "DummyCommand"; 
    Command.CommandType = CommandType.StoredProcedure; 

    Connection.Open(); 

    using (IDataReader reader = Command.ExecuteReader()) 
    { 
     DataTable Result = new DataTable(); 
     Result.Load(reader); 
     return Result; 
    } 
    } 
} 

Con esta técnica puedes crear DAL independiente totalmente db. Por supuesto, para algunos escenarios complejos esto no es suficiente. Pero principalmente esto hará el trabajo, y usted no necesita varias libretas externas.

2

En general, solicité la recomendación de John Nolan de Patterns of Enterprise Application Architecture.

Más específicamente, siempre recomendaría que oculte su capa de acceso a datos detrás de una interfaz y use Inyección de dependencia para inyectar un componente de acceso a datos en particular en su lógica de dominio en tiempo de ejecución.

Puede usar un Endependent Injection Container o do it manually.

En cuanto a la tecnología, recomendaría Microsoft Entity Framework, ya que sus necesidades de acceso a los datos parecen estar limitadas a las bases de datos relacionales. Entity Framework es el OR/M oficial de Microsoft y tiene proveedores para muchos RDBMS diferentes, así como soporte LINQ.

1

Realmente depende del tamaño de su capa y del tipo de producto que desarrolle. Si está bastante bien contenido, entonces ADO.NET probablemente sea ideal. Si se trata de una capa DAL más grande, y su desarrollo totalmente nuevo de dbms multidireccionales, es mejor utilizar una herramienta ORM. Son productos rápidos, eficientes y maduros, y pueden permitir rápidamente la reorientación a otro DB, simplemente cambiando un solo parámetro. Escribir ADO estático es algo que está pasando al legado.

Existen varias herramientas ORM que pueden hacer el trabajo, todas funcionan ligeramente diferente, y dependen de en su presupuesto, tamaño de su equipo, etc. Pueden funcionar escribiendo una clase de mapeo como NHibernate o trabajando a través de reflexión, es decir, marcado de atributo.

De forma gratuita, es decir, de código abierto, si su skint, NHibernate es ideal. Estoy usando esto en este momento, para construir la capa DAL, para un producto enteprise grande. Es excelente, pero tómate un tiempo para dominar. Con NHibernate usted define las clases de mapeo, que cuando se ejecutan generan el modelo db por usted. Es compatible con procedimientos almacenados. La desventaja es que lleva algo de tiempo aprender, especialmente cuando se mapean correctamente datos complejos. Es excelente. Tiene un gran paquete de muestras y otros proyectos flotando sobre eso lo usó. Echa un vistazo a Koders.com.

Si tiene un poco de presupuesto, entonces LLBLGen es ideal. Está fuertemente tipado y también admite procedimientos almacenados.

Si algunos de los modelos de datos ya están disponibles, entonces TierDeveloper es ideal. Es esencialmente gratuito y funciona desarrollando un conjunto de clases a partir de su modelo de base de datos. El único inconveniente es que el mapeador de MySQL es de terceros. Es un producto de clase enteprise que se ha hecho libre para admitir ncache, y es un posible enfoque.

Si está desesperado por quedarse con MS, se están moviendo hacia ORM, y tienen un producto llamado ADO.NET Entity Framework. Funcionalmente no es tan completo como las herramientas definidas anteriormente. Tiene cerca de 3 generaciones de retraso en la madurez. Está disponible en vs 2008 sp1. El conector para mysql sería un costo.

Además, podría usar LINQ. También se dirigirá a mysql, si también necesita el conector.

Idealmente, su mejor apuesta es con ORM. Si no puede admitir código abierto, y tiene presupuesto, , obtenga

Espero que ayude.