Buscar
Social
Ofertas laborales ES
« Liberado Weld 1.0. RC1 (el antiguo Web Beans) | Main | Los 50 mejores trabajos en América »
jueves
oct222009

Otra vez con los ORM

Este fin de semana en DZone se ha publicado un post llamado <a href="http://codemonkeyism.com/orms/">ORMs are a thing of the past</a>.A raiz de ésto ya ya llevan publicados otros 4 post para contestarle:

  • <a href="http://java.dzone.com/news/orm-debate-obsolete-technology">The ORM Debate: Experts Weigh In</a> 
  • <a href="http://java.dzone.com/articles/are-orms-really-thing-past">Are ORMs Really a Thing of the Past?</a>
  • <a href="http://blog.schauderhaft.de/2009/10/18/hibernate-problems-alternative/">Hibernate has Problems, but where is the Alternative?</a>
  • <a href="http://www.crazymcphee.net/x/2009/10/19/orm-is-dead-meme/">ORM-is-Dead meme</a>

Lo sorprendente es que haya habido varias respuestas a un tema que ya se daba por zanjado. Pero lo interesante es ver voces discordante con el "sentir" general. Mi impresión es que hablar en contra de la corriente general suele ser tabú y se suele quedar como un ignorante con lo que uno acaba por no discrepar.El ejemplo más famoso fué en el los EJB hace ya años.

Por ello aprobechando estos post voy a comentar algunas cosas sobre los ORM y persistencia con los que no estoy de acuerdo:

  • Los ORM permiten que se cambie el esquema de la base de datos: Esto es cierto pero lo normal es que sea más estable la base de datos que la propia aplicación.Las app van y vienen pero las bases de datos se mantienen.
  • Los ORM se ahorran gran catidad de SQL:Tambien es cierto pero de todas esas SQL la mayoría pueden ser para hacer un CRUD de cada una de las tablas.En una mañana se puede hacer el código que te genera automáticamente las 4 SQLs por tabla.Y para el resto quizas es mejor hacerlas a mano que dejarselas al ORM.
  • Las validaciones de los ORM: Nunca he entendido pq Hibernate (o cualquier otro) tiene una sola linea de código para hacer validaciones.La validaciones deben estaar en la capa de negocio y los ORM están en la de persistencia. Ya se que nadie te obliga a usarlas pero están ahí y al final uno no se pregunta si debe o no usarlas, con lo que acaba usándolas.
  • Oponer un ORM a ActiveRecord: Los ORM se dedican a la persistencia y el ActiveRecord también así que el ActiveRecord también es un ORM.
  • El ActiveRecord permite la persistencia de una única tabla: ¿Hay alguna ley que prohiba que actue sobre más de una tabla? El ActiveRecord lo único que tiene es que los métodos de "save", "delete", "read", etc. Se encuentran en la propia clase de negocio lo demás son limitaciones que alguien impondría alguna vez y el resto repetimos como loros.
  • Con el ActiveRecord se mezclan el código de negocio con el de  persistencia:¿Acaso el ActiveRecord no puede delegar la persistencia a otra clase? La duda sería entonces pq usar ActiveRecord si luego no hacen la persistencia dentro. La respuesta es simplemente para mantener el interfaz de las operaciones de "save", "delete", etc en la propia clase. Para mi es mucho más cómodo que tener que buscar un nuevo objeto que las persista.
A estas horas no se me ocurre nada más pero valga ésto para no caer en la complacencia y pensar que las cosas ya están bien como están.

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.
Comentarios deshabilitados
Comentarios deshabilitados en esta noticia.