IdbConnection vs. SqlConnection

Question

Cuando escribo una aplicación, utilizo las interfaces System.Data (IDbConnection, IDbCommand, IDataReader, IDbDataParameter, etc ...). Lo hago para reducir las dependencias de los proveedores. A menos que haga una aplicación de prueba simple, parece ser lo ético que se debe hacer cuando se consulta.

Sin embargo, parece que todo el código que veo utiliza las clases de espacio de nombres System.Data.SqlClient u otras clases específicas del proveedor. En revistas y libros, es fácil atribuir esto a la influencia de Microsoft y su estrategia de marketing para programar solo contra SQLServer. Pero parece que casi todo el código .NET que veo utiliza las clases específicas de SQLServer.

Me doy cuenta de que las clases específicas del proveedor tienen más funcionalidad, por ejemplo, agregar un parámetro a un objeto SqlCommand es un método, mientras que agregarlo a un IDbCommand es irritante 4+ líneas de código. Pero entonces de nuevo; escribir una pequeña clase de ayuda para estas limitaciones es bastante simple.

También me he preguntado si la programación en contra de las interfaces cuando SQLServer es el cliente objetivo actual es una sobreingeniería ya que no se requiere de inmediato. Pero no creo que sea así, ya que el costo de programación frente a las interfaces es muy bajo, mientras que la reducción de la dependencia del proveedor proporciona un beneficio tan grande.

¿Utiliza clases de datos específicas del proveedor o las interfaces?

EDITAR: Para resumir algunas de las respuestas a continuación, e invertir algunas reflexiones que tuve al leerlas.

posibles peligros en el uso de interfaces para el vendedor neutralidad: palabras clave específicas

• proveedores incrustados en instrucciones SELECT (todos mis ins, UPD, & Del'S están en procsos, así que eso es no es un problema)
• Enlazando directamente la base de datos probablemente causaría problemas.
• A menos que su conexión la instanciación esté centralizada, la clase específica del proveedor necesitará llamar a de todos modos.

razones positivas para utilizar interfaces:

• En mi experiencia, la capacidad (incluso si no se ejerce ) para mover a un proveedor diferente siempre ha sido apreciado por el cliente.
• utilizan interfaces en las bibliotecas de código reutilizable

Answer 1

Hay diferencias con el SQL que va a tener que dar a las clases, dependiendo del tipo de motor de base de datos con el que está hablando, por lo que incluso si logra escribir todo su código para usar las interfaces, Todavía es necesario escribir múltiples conjuntos de SQL.

O bien, puede hacer lo que hemos hecho, escribir nuestra propia capa que se encarga de toda la sintaxis que usamos, que no es toda la sintaxis proporcionada por los diferentes motores, pero suficiente para escribir un SQL que se reescribe correctamente antes de la ejecución.

Básicamente, hemos creado una sintaxis de función en la que prefijamos los nombres de las funciones con SQL::, lo que permite que nuestro código identifique las funciones especiales que deben reescribirse. Luego se analizan y se reescriben correctamente, incluso si es necesario cambiar el orden de los argumentos.

Se pueden hacer cosas pequeñas como el nombre de la función que devuelve la fecha y la hora actuales del servidor, pero también cosas más grandes, como cómo seleccionar las primeras N filas de una consulta.

Además, los parámetros para SQL Server están escritos como @name, donde OleDb usa posicional (simplemente agregue un? Donde desea el parámetro), y nuestro código maneja esas diferencias también.

Vale la pena en el sentido de que no nos preocupamos demasiado por el SQL que debe escribirse.

Answer 2

utilizo las clases específicas del vendedor donde yo estoy haciendo el trabajo db directa (a menos que me han dicho que es una posibilidad que puede terminar con otra base de datos - número de veces eso ha sucedido: una vez).

Sin embargo, si termino descomprimiendo un código específico no-db en clases separadas, a menudo haré las interfaces de parámetros de método, especialmente si creo que será útil en otros proyectos, y no estoy confiando en cualquiera de las características específicas de la clase de acceso directo.

Básicamente, parafraseando a Einstein: Haga la solución lo más simple posible, pero no más simple.

Answer 3

Una cosa a tener en cuenta es la posibilidad real de que alguna vez cambie de base de datos. En la mayoría de los casos, esto nunca sucederá. E incluso si lo hace, será una reescritura importante, incluso si utiliza clases que son de base de datos neutral. En este caso, probablemente sea mejor usar cualquiera que sea más rico en características y lo ayudará a terminar el proyecto más rápido.

Dicho esto, creo que en la mayoría de los casos, debe usar una capa que cree usted mismo, por encima de la API .Net real, de modo que si alguna vez tiene que cambiar las clases que tiene que usar, entonces no lo hará ser un gran problema Incluso si permanece en la misma base de datos, nunca sabrá cuándo tendrá que cambiar la forma en que accede a la base de datos. Cualquiera que haya migrado de ASP a ASP.Net (ADODB vs. ADO.Net) puede decirle cuánto de dolor es esto.

Creo que la mejor solución es utilizar la API más rica en características de la base de datos específica, y construir su propia capa encima, para que pueda cambiarla fácilmente si es necesario.

Answer 4

Escribía algo similar a lo que decía lassevk, pero él me golpeó.

Además,, tiene que hablar con una base de datos real en algún momento. Es posible que pueda evadir la mayor parte de su acceso de datos con el código de interfaz, y esa es una buena idea. Pero eventualmente, si está usando SQL Server, querrá crear una instancia real de SqlClient.SqlConnection. Lo mismo para Access, Oracle o MySQL.

Answer 5

Debería intentar escribir su código de base de datos de forma independiente. Tal vez no lo encuentre útil en este momento pero probablemente lo aproveche en el futuro.

Answer 6

Eche un vistazo a la biblioteca Enterprise del grupo de patrones y prácticas de Microsoft. El código de acceso a datos que tienen allí muestra algunas buenas implementaciones de independencia del proveedor.

http://msdn.microsoft.com/en-us/library/cc467894.aspx