2010-05-30 26 views
7

Estoy buscando una forma de escribir una declaración de SQL en C# dirigida a diferentes proveedores. Un ejemplo típico de diferenciación de sentencias SQL es LIMIT in PostgreSQL frente a TOP in MSSQL.Creador de SQL genérico .NET

Es la única forma de resolver la sintaxis SQL como las dos anteriores para escribir sentencias if dependiendo de qué proveedor selecciona el usuario o usar declaraciones catch catch como control de flujo (LIMIT no funcionó, lo intentaré TOP en su lugar)? He visto el método LINQ Take, pero me pregunto si se puede hacer esto sin LINQ.

En otras palabras, ¿tiene C# alguna clase de proveedor de SQL genérico que no he podido encontrar que pueda usarse?

+1

¿Por qué no quieres usar LINQ? –

+0

Hay muchas maneras de resolver estas diferencias, ¿está seguro de que usar SQL es la manera de hacerlo, es decir, encontrar algún sistema que le permita escribir una declaración SQL que funcione en diferentes proveedores? –

+0

@Mark Byers: Bueno, a menudo me estoy enfocando en .NET 2 y, hasta donde yo sé, LINQ no funciona tan bien allí. Históricamente, esto se debía a que quería poder realizar un cambio en Mono sin ningún tipo de fuzz, y luego simplemente me "atascaron". Como Mono funciona bien con LINQ hoy en día, realmente no puedo dar ninguna otra buena respuesta por la que sigo viviendo en el pasado ... – Patrick

Respuesta

7

Entity Framework puede apuntar a diferentes bases de datos. Esto le permitiría escribir declaraciones LINQ que funcionarían con ambas bases de datos. Necesitaría encontrar un proveedor postgresql para Entity Framework. Hay varios para elegir.

Espero que esto ayude.

3

Hay DBLinq:

proveedor de LINQ para Oracle, PostgreSQL, MySQL, Ingres, SQLite, Firebird y SQL Server ... (C# 3,0)

Cuando se genera una consulta mediante LINQ to SQL es posible ver el SQL generado y guardarlo.

Sin embargo, no cumple con su requisito "sin usar LINQ". Si tiene LINQ disponible, ¿por qué no usarlo?

3

No creo que haya un "proveedor genérico de sql".

En nuestra tienda necesitamos dar soporte tanto a DB2 como a SQL Server, por lo que decidimos implementar un patrón de capas creando clases de Modelo, Acceso a datos y Lógica empresarial. La capa de acceso a datos maneja la conexión a los diferentes DBMS y carga las clases de modelo devolviéndolas a la lógica de negocios. La lógica de negocios y las clases de modelos no tienen idea de dónde la capa de acceso a datos obtiene los datos.

Las diferencias en SQL se manejan porque la capa de acceso a datos llama a los procedimientos almacenados en la base de datos. Tenemos los procedimientos almacenados implementados con la sintaxis apropiada en ambos sistemas. Si necesitamos ir a otra base de datos, todo lo que tenemos que hacer es implementar los procedimientos necesarios en los nuevos DBMS y todo debería funcionar.

+0

Ouch, mi primer voto negativo. Una explicación sería apreciada. Gracias. –

+0

Entonces, básicamente, ¿implementas la tuya? :-) Los procedimientos almacenados no son un "estándar" entre las bases de datos hasta donde yo sé, aunque es un buen punto ya que reduce los errores que pueden ocurrir al trabajar con la lógica de negocios. Estaba buscando una manera de, por ejemplo, listar tablas en un archivo db y luego obtener las columnas de una tabla particular en "cualquier base de datos", en cuyo caso S.P. no es tan bueno como una coincidencia. – Patrick

+0

Veo, su pregunta no detalla el requisito de "descubrir" objetos de base de datos, esto va más allá de las diferencias en las implementaciones de SQL. Gracias por la explicación y entiendo que esto no es lo que estás buscando y, por lo tanto, el voto a la baja. –

1

Unirse a la idea de Marc Tidd - Si no desea Linq, cree clases DAL separadas para cada proveedor, o utilice procedimientos almacenados que se implementarán en cada DB.

+0

Sí, la idea principal para resolver el problema de SQL es el uso de procedimientos almacenados, no tiene que pasar por el patrón de capa completa si no se ajusta a su solución. –