Programando JDBC vs. Frameworks
Cuando en un proyecto JAVA te planteas como vas a realizar la persistencia de la información, debes elegir si vas a utilizar algún framework, como Hibernate, EJBs, Expresso,... o vas a acceder directamente programando con JDBC.
Algunos puntos interesantes a tener en cuenta pueden ser estos:
Algunos puntos interesantes a tener en cuenta pueden ser estos:
- Velocidad de desarrollo: Pues típicamente aquí ganan los frameworks, claro que lo más influye realmente es la experiencia en cada campo. Teóricamente, los frameworks nos permiten abstraernos de los problemas de la BBDD.
- Eficiencia: Los frameworks más utilizados en JAVA, como Hibernate presumen de utilizar numerosas técnicas para minimizar el impacto del mismo en la BBDD, y de optimizar incluso los accesos. En mi opinión, únicamente se pueden exprimir al máximo todas las posibilidades de JDBC accediendo a este directamente, donde te preocupas que cada SQL o proceso batch se haga de la manera ideal.
- Eficacia: ¿Nunca os habeis encontrado con alguna limitación que os ha obligado a bajar de nivel (a JDBC) o a realizar las cosas con su típico "work-around" (como dice Oracle) :) ?
- Curva de aprendizaje: Este punto depende del mundo del que vengas. Si sabes mucho SQL, entonces JDBC será más fácil. Si dominas JAVA al dedillo y no te cuesta nada hacerte con nuevos APIs, y crees que las BBDD son cosas de los de sistemas, probablemente te engancharas a un framework como a un enchufe.
Tú eliges.
Mi Twitter
Bueno, estoy en parte de acuerdo con lo que dices pero querría hacer alguna puntualización desde mi punto de vista.
ResponderEliminarVelocidad de desarrollo: es claramente mucho más rápido utilizar un framework que programarte a mano toda la capa de modelo de datos. Incluso puede ser posible construir partes de la aplicación, como formularios de edición/creación o listados, de forma semi autómatica, utilizando los metadatos del sistema de persistencia o reflection, por ejemplo.
Eficiencia: los sistemas de persistencia suelen ofrecer mecanismos de caché que permiten en muchas ocasiones recuperar elementos sin tener que acceder a base de datos. A esto hay que añadir otras mejoras como la carga retardada de elementos relacionados (1:N) mediante la utilización de proxys, definición de dependencias entre contenidos provocar borrados en cascada en la caché...
Eficacia: en principio un buen framework debería obligarnos únicamente a acceder directamente al sistema de almacenamiento en casos muy justificados, normalmente relacionados con temas en los que es primordial la eficiencia en el acceso a los datos.
Curva de aprendizaje: creo que una cosa no quita la otra, conviene tener conocimientos de bases de datos, utilices frameworks o no. Desde luego el aprendizaje de un framework supone más trabajo, sobre todo teniendo en cuenta la gran cantidad de ellos que hay y que seguramente ninguno nos convenza al 100%, sin embargo creo que hay que verlos como una herramienta más para la realización de aplicaciones, que nos puede permitir ahorrar gran cantidad de tiempo en el desarrollo.
Yo pondría otro apartado más:
Abstracción: un framework de persistencia puede permitir abstraernos en gran medida del sistema de almacenamiento utilizado, pudiendo en muchas ocasiones mezclar almacenamiento en bases de datos relacionales, archivos XML o incluso datos provenientes de servicios web, todo ello de forma completamente transparente para las capas superiores.
Buenas puntualizaciones. Aunque el tema de eficiencia, que aún siendo verdad, por supuesto, lo que dices, sigo pensando que a veces "se notan".
ResponderEliminarY la abstracción desde luego que es otra característica importante, aunque a veces me da más miedo que otra cosa, por que puedes realizar cosas sin tener en cuenta que sucede por abajo. (auqnue reconozco que en el 90% de los casos ni falta que hace)
Respecto a la eficiencia es inevitable que se note. Los framework pueden disponer de opciones que minimicen la pérdida de eficiencia que suponen, e incluso en algunas circunstancias la mejoren, pero es cierto que en muchas ocasiones se pierde eficiencia. Ahí está la elección de un buen framework, utilizarlo correctamente y saber cuándo acceder directamente a los datos. Ten en cuenta de todas formas, que muchas veces es más rentable comprar más "hierro" que gastar dinero en desarrollo, por lo que esa pérdida de eficiencia se puede recuperar invirtiendo parte del dinero que costaría el desarrollo sin ella, en más hardware por ejemplo. Pero sin que ello justifique el hacer programas basura. Hay que saber encontrar el punto medio ;)
ResponderEliminar