¿Hasta dónde debemos abstraernos?

Mientras que los creadores de Symfony se esfuerzan para que Doctrine se integre completamente con el framework y se convierta en su ORM por defecto, François Zaninotto se esfuerza para que deje de ser importante utilizar un ORM u otro.

François es el creador del plugin DbFinderPlugin, que entre otras cosas permite:

  • Simplificar al máximo el desarrollo de la parte del modelo (olvídate de Criteria y de las clases peer).
  • Mejorar las posibilidades de Propel añadiéndole características que no incluye de forma nativa.
  • Compatibilidad para que el mismo código pueda funcionar tanto con Propel como con Doctrine.

Esta última característica es la más espectacular, ya que cuando esté completamente desarrollada ya no será importante elegir el ORM de trabajo. La idea de DbFinderPlugin es proporcionar una capa de abstracción adicional por encima del ORM para que el mismo código fuente pueda funcionar con cualquier ORM.

François ha publicado un artículo en su blog explicando cómo ha reescrito el plugin sfSimpleBlog utilizando esta nueva capa de abstracción. Aunque no se menciona el impacto que tiene esta capa sobre el rendimiento de la aplicación, la reducción y simplificación del código es muy significativa:

// Clase original
public static function getTagged($tag, $max)
{
  $c = new Criteria();
  $c->addJoin(sfSimpleBlogTagPeer::SF_BLOG_POST_ID, self::ID);
  $c->add(sfSimpleBlogTagPeer::TAG, $tag);
  $c->add(self::IS_PUBLISHED, true);
  $c->addDescendingOrderByColumn(self::CREATED_AT);
  $c->setLimit($max);

  return sfSimpleBlogPostPeer::doSelectJoinAll($c);
}

// Clase que utiliza DbFinderPlugin
public function tagged($tag)
{
  return $this->
    join('sfSimpleBlogTag')->
    where('sfSimpleBlogTag.Tag', $tag);
}

Aunque el uso de DbFinderPlugin parece una idea brillante para que todos los plugins sean compatibles con todos los ORM existentes, ¿realmente merece la pena añadir otra capa de abstracción? ¿Es lógico abstraerse tres niveles (DbFinder → ORM → PDO) hasta la base de datos? ¿Merece la pena la penalización en el rendimiento?

Comentarios

  1. Pues yo creo que si. Al menos que nos permitan tener esa posibilidad. Si manana se les ocurre usar otro ORM mejor aun de los dos que ya disponemos, y que nos traiga mas beneficios aun. No veo porque renunciar, y con ello, a los plugins y desarrollos actuales. Simplemente estudiamos de actualizar este META-ORM. Por el rendimiento, he visto poco impacto.

    Creo que como gestores de soluciones que usamos Symfony, apreciaremos la reutilizacion de codigo. Cualquier otra direccion diezmaria a este gran framewok.

    Un meta-ORM, permitiria homogeneizar codigo, pero no implicaria discriminar a aquellos que desean seguir con un ORM. La idea es sumar....

    puentesdiaz el 14 de agosto de 2008, 19:47:52

  2. esto es simple.... para que usar una capa mas si en tu proyecto tu ORM no cambiara??? para que agregar una capa mas que podria traducirse en performance. ademas , una ventaja del ORM es que permite cambiar de DB de ahi a poner otra capa para cambiar de ORM lo veo como irse muy fino. la verdad preferiria que Francois le metiera mas al propel 1.3 dado que sensio contrato al programador de doctrine, ahi si se pondria interesante

    ismael el 15 de agosto de 2008, 1:12:02

  3. La idea es poder reutilizar todo elcodigo disponible. Pregunta: SI nuestro sistema usa plugins de diferentes ORM , podemos usar dos ORM dentro de nuestro proyecto? o al menos para esos plugins? Si esto es asi, no haria falta un METAORM, peri sino..... podria decir que es indispensable.

    puentesdiaz el 15 de agosto de 2008, 2:17:34

  4. @ismael la idea de utilizar el DbFinderPlugin es poder hacer plugins que funcionen bajo cualquiera de los actuares ORM (Propel 1.2, Propel 1.3 y Doctrine). Yo diria que este seria su unica ventaja, porque la realidad es que seria demaciado raro cambiar de ORM en tu proyecto. Pero si esta perfecto para crear plugins sin procuparte por el ORM.

    Daniel el 15 de agosto de 2008, 2:22:50

  5. Plugins que funcionen bajo cualquier ORM, mmm y el performance?, si veo la ventaja, pero si esto acarrea una carga mas en tiempo de proceso pues pierde ventaja.

    ismael el 15 de agosto de 2008, 17:20:16

  6. A mi me parece genial la idea, pero solo el tiempo y las pruebas permtiran determinar si el procesamiento de esta capa perjudica mucho la aplicación. No se puede dejar el rendimiento de la aplicacion solo en el ORM, con un buen analisis de cache se puede potencializar una aplicacion, no hablo de la cache comun y corriente, la de segundos, sino una super cache que sea permanente, pero eso solo depende de casos particulares de la aplicacion.

    > @ismael : "para que usar una capa mas si en tu proyecto tu ORM no cambiara??" En algunas empresas se desarrollan aplicaciones genericas reutilizables y por ejemplo para algun proyecto no se puede tener un servidor que soporte doctrine o propel 1.3, que hago? reescribir para propel1.2. ahi funciona esta capa. Otro ejemplo muy comun es migrar sistemas para que usen servicios web (ws), es una practica muy común sobre todo con las nuevas tecnologias, se podria dar el caso de implementar un ORM que funcione con Web Services y no habria que recodificar mis antiguas aplicaciones (Sobre esto yo todavia tengo la esperanza que Yahoo algun dia comparta con la comunidad la forma en que usa WS para Yahoo respuestas!)

    Leonardo Diaz el 17 de agosto de 2008, 0:27:55

  7. Creo que Symfony está sacando demasiadas versiones con muchos cambios en poco tiempo. Realmente era tan malo Propel para dejarlo tan rápidamente?

    John el 19 de agosto de 2008, 14:25:51

Este artículo ya no permite añadir más comentarios.
¿Por qué? Los artículos cierran sus comentarios automáticamente unos meses después de su publicación para asegurar que estos sigan siendo relevantes.

Publicada el

14 de agosto de 2010

Etiquetas

Proyectos Symfony destacados

La forma más sencilla de generar el backend de tus aplicaciones Symfony. Ver más

Síguenos en @symfony_es para acceder a las últimas noticias.