Existen numerosas formas de conectarse e interactuar con la capa de la base de datos. En Java, por ejemplo, los usos comunes son JDBC llamadas de SQL sin procesar, mapeadores relacionales de objetos, JDBCTemplate (Spring), procedimientos almacenados, etc.¿Cuál es tu forma favorita de interactuar con bases de datos desde tu lenguaje de programación?
En su idioma, ¿qué opción prefiere y por qué? ¿Cuándo considerarías a los demás?
ORM cada vez, al menos tengo que pensar en las bases de datos, mejor.
Prefiero construir una capa de modelo de objeto de negocio (objetos y coleccionismo de objetos).
Creo la capacidad de interactuar con la base de datos en cada objeto/colección (para SQL Server, yo uso System.Data.SqlClient). He utilizado este patrón para SQL Server, MySQL y Oracle.
Luego interactúo con los objetos de mi código de aplicación.
Al abstraer mi base de datos en objetos, el código de mi aplicación es consistente independientemente de la base de datos back-end.
LINQ es el camino a seguir para mí de aquí en
me gusta mucho el 3 + 1 niveles manera de hacer las cosas. Un nivel para la interfaz de usuario, otro para lógica empresarial y para datos persistentes. ¿El último que dices? Objetos de dominio e interfaces. Esto permite cargar uno o dos de los niveles principales más el "nivel" de dominio, y el código debería funcionar.
Se basa en gran medida en dependency injection y principios. El nivel de datos/persistencia solo hace dos cosas. Crea, lee, actualiza y elimina datos, y los mapea en el formato del objeto de dominio.
El nivel UI hace exactamente lo contrario. Muestra y recibe datos de una manera que el usuario puede relacionar, y mapea esa salida/entrada ay desde el formato de objeto de dominio.
El nivel lógico de negocios solo necesita saber una cosa. Lógica de negocios. No le importa de dónde provienen los datos, y no le importa dónde está ubicado el nivel de datos. Sabe que debe marcar una cuenta que acaba de sobregirar, cómo hacer eso físicamente no es realmente parte de su trabajo.
Los propios objetos de dominio no tienen ninguna lógica, solo son contenedores para pasar datos entre los niveles. Esto significa que puede cargar los objetos de dominio y las interfaces sin tener que pensar en absoluto sobre las dependencias.
Al final del día, siento que tengo una base de código bastante clara con niveles claramente separados. Y con algunas interfaces estrictas y buenas clases de base, la mayoría de la codificación solo le dice al software qué hacer cuando sucede X. Cómo se supone que es.
</rant>
Edit: Oh, sí. Esto es cierto para LINQ, SubSonic y otros ORM.
ORM es realmente fantástico.
Uso SQL Alchemy cuando trabajo en python, funciona con casi todos los DBMS que he encontrado.
Para aplicaciones basadas en datos de peso ligero en MacOS X, uso de datos básicos, que tiene una gran herramienta de modelado de datos accesible a través de Xcode.
Ambos muestran que ORM hecho a la derecha es excelente. He tenido menos éxito y disfrute con EJB.
no he metido en el mundo de LINQ aún, pero realmente he llegado a querer las clases/TableAdapter DataTable que Visual Studio ha hecho por medio de un conjunto de datos XSD. Por medio de unos pocos arrastres y clics después de crear mi esquema de base de datos, ahora tengo un objeto DataSet/DataTable fuertemente tipado y tengo métodos de adaptación que están usando consultas parametrizadas a mis procedimientos almacenados para todas mis declaraciones CRUD. Incluso creará adaptadores de tablas de consulta para algunos de esos procedimientos que no están directamente vinculados a una tabla.
Ah, y si no se ha creado aún los procedimientos almacenados y sólo tiene las tablas, el asistente creará los procedimientos o las declaraciones ad hoc SQL para usted.
Esto ha estado fuera desde Visual Studio 2005 y ha reducido drásticamente en mi "estructura" tiempo con mis nuevas aplicaciones web y puede centrarse más en la lógica de negocio y presentación.
En C# Me encanta LINQ to SQL para nada nuevo, pero me gusta mucho el uso de .netTiers + CodeSmith Generator para obtener una capa de datos rápida y sucia a la base de datos ocurre si estoy usando C# en .NET 2.0.
Ruby on Rails' ActiveRecord limpia el piso con todo lo demás que he visto hasta ahora. LINQ parece que podría ser mejor en algunos casos, pero ActiveRecord es tan flexible.
me gusta mucho :) Hibernate
sé que tiene una curva de aprendizaje, pero una vez que has dominado, es bastante agradable.
Ni que decir tiene, no puedo esperar para poner mis manos sobre el nuevo Entity Framework en .NET 3.5 SP1 (sé que ya está disponible, pero soy un poco vago para escribir XML :))
ActiveRecord , que es un patrón documentado primero (creo) en Fowler's Patterns of Enterprise Architecture. Creo que está implementado en otros idiomas además de Ruby, aunque es bien conocido como una tecnología básica en Rails. Como sea, es una clara abstracción de la base de datos, aunque debo confesar que me parece un poco torpe y en el área de find_by_sql. Pero eso puede ser solo yo.
Pero (poniendome ahora el sombrero de Grumpy Old Man) todos los ORMs en el mundo no son un sustituto para un buen conocimiento de SQL, sin los cuales realmente no me gustaría ver el acceso a un RDBMS.
Actualmente estamos usando ODAC para hablar con la base de datos Oracle y utilizar muchos Paquetes Oracle (PL/SQL). El sistema n-tier se realiza a través de RemObjects, lo que significa que nuestro cliente no tiene ningún SQL en absoluto y solo necesita la capacidad de enviar solicitudes HTTP para que no haya gastos generales de instalación.
Todo esto se hace utilizando Borland Delphi y se ha woking durante 2 años en un entorno de producción.
Utilizamos un enfoque mixto, dependiendo de lo que se adapte a la situación particular dentro de la aplicación:
Esto es con Java/Oracle.
Utilizamos Delphi y Oracle Data Access Components (ODAC) y ADO a través de Oracle.OleDBProvider.
La forma favorita de mayo es utilizar Smalltalk con un repositorio de objetos GemStone. ¿Por qué? No hay problema de ORM para tratar. Solo consideraría otra cosa si mi empleador me obliga o amenaza.
Mi forma favorita es tener una capa de abstracción de objetos. Idealmente, este es único lugar que funciona con SQL. Pero en la práctica, los objetos a veces también necesitan hacer SQL-y cosas. Pero nada fuera del objeto.
Hasta ahora, he escrito esas capas porque lo que estaba disponible era demasiado incómodo, demasiado lento o demasiado grande.
Uso JDBC simple porque estoy desarrollando una aplicación basada en datos y mi modelo de base de datos es muy complejo. Todo se describe en la base de datos, incluso la estructura de otras tablas. Además de esto, utilizo mucho los procedimientos almacenados. Por lo tanto, ORM no es una opción para mí.
¿Qué sucede si quiere leer 10000 filas de la base de datos y almacenar el total en alguna parte? ¿Por qué arrastrar todo eso a través de la red cuando podía: insertar en totales ... seleccionar de los detalles? –
Con un ORM, no tiene que leer 10000 filas para obtener el total. Por ejemplo, en LinqToSql es posible utilizar un método Sum para hacer una suma de una propiedad, que luego se convierte en SQL adecuado que permite al servidor sql calcular la suma sin devolver todas las filas. –
@Ole: LinqToSql (que solo es compatible con SQL Server, y puede que ya esté muerto a favor de Entity Framework) sigue siendo una caja negra, ¿por qué no escribir el SQL usted mismo? Y si coloca la lógica de resumen en un procedimiento almacenado, no necesita dar acceso sin formato a la aplicación a sus tablas. – ObiWanKenobi