Después de usar Hibernate en la mayoría de mis proyectos durante aproximadamente 8 años, llegué a una empresa que desalienta su uso y quiere que las aplicaciones solo interactúen con la base de datos a través de procedimientos almacenados.
Después de hacer esto durante un par de semanas, no he podido crear un modelo de dominio rico de la aplicación que estoy comenzando a compilar, y la aplicación solo parece un script transaccional (horrible).
Algunos de los problemas que he encontrado son:
- No se puede navegar por el gráfico de objetos, ya que los procedimientos almacenados solo cargan la cantidad mínima de datos, lo que significa que a veces tenemos objetos similares con diferentes campos. Un ejemplo es: tenemos un procedimiento almacenado para recuperar todos los datos de un cliente, y otro para recuperar la información de la cuenta, además de algunos campos del cliente.
- Gran parte de la lógica termina en clases auxiliares, por lo que el código se vuelve más estructurado (con entidades utilizadas como estructuras de C antiguas).
- Código de andamio más aburrido, ya que no hay un marco que extraiga conjuntos de resultados de un procedimiento almacenado y lo coloque en una entidad.
Mis preguntas son:
- ¿Alguien ha estado en una situación similar y no estuvo de acuerdo con el enfoque del procedimiento de la tienda? ¿Qué hiciste?
- ¿Existe un beneficio real de usar procedimientos almacenados? aparte del punto tonto de "nadie puede emitir una tabla desplegable".
- ¿Hay alguna manera de crear un dominio rico utilizando procedimientos almacenados? Sé que existe la posibilidad de utilizar AOP para inyectar DAO / repositorios en entidades para poder navegar por el gráfico de objetos. No me gusta esta opción, ya que está muy cerca del vudú.
Conclusión
Primero, gracias a todos por sus respuestas. La conclusión a la que he llegado es que los ORM no permiten la creación de modelos de dominio enriquecido (como algunas personas mencionaron), pero sí simplifica la cantidad de trabajo (a menudo repetitivo). La siguiente es una explicación más detallada de la conclusión, pero no se basa en ningún dato sólido.
La mayoría de las aplicaciones solicitan y envían información a otros sistemas. Para hacer esto, creamos una abstracción en los términos del modelo (por ejemplo, un evento de negocios) y el modelo de dominio envía o recibe el evento. El evento generalmente necesita un pequeño subconjunto de información del modelo, pero no todo el modelo. Por ejemplo, en una tienda en línea, una pasarela de pago solicita cierta información del usuario y el total para cobrar a un usuario, pero no requiere el historial de compras, los productos disponibles y toda la base de clientes. Por lo tanto, el evento tiene un conjunto pequeño y específico de datos.
Si tomamos la base de datos de una aplicación como un sistema externo, entonces necesitamos crear una abstracción que nos permita mapear las entidades del Modelo de Dominio a la base de datos ( como mencionó NimChimpsky , usando un mapeador de datos). La diferencia obvia es que ahora necesitamos crear una asignación para cada entidad modelo a la base de datos (ya sea un esquema heredado o procedimientos almacenados), con el dolor adicional de que, dado que los dos no están sincronizados, una entidad de dominio podría mapearse parcialmente a una entidad de base de datos (por ejemplo, una clase de UserCredentials que solo contiene nombre de usuario y contraseña se asigna a una tabla de Usuarios que tiene otras columnas), o una entidad de modelo de dominio podría asignar a más de una entidad de base de datos (por ejemplo, si hay una una asignación en la tabla, pero queremos todos los datos en una sola clase).
En una aplicación con algunas entidades, la cantidad de trabajo adicional puede ser pequeña si no hay necesidad de atravesar las entidades, pero aumenta cuando hay una necesidad condicional de atravesar las entidades (y, por lo tanto, podríamos querer implementar algún tipo de 'perezoso' cargando'). A medida que una aplicación crece para tener más entidades, este trabajo solo aumenta (y tengo la sensación de que aumenta de forma no lineal). Mi suposición aquí es que no intentamos reinventar un ORM.
Una ventaja de tratar la base de datos como un sistema externo es que podemos codificar situaciones en las que queremos que se ejecuten 2 versiones diferentes de una aplicación, en las que cada aplicación tiene una asignación diferente. Esto se vuelve más interesante en el escenario de entregas continuas a la producción ... pero creo que esto también es posible con ORM en menor medida.
Voy a descartar el aspecto de seguridad, sobre la base de que un desarrollador, incluso si no tiene acceso a la base de datos, puede obtener la mayoría, si no toda, la información almacenada en un sistema, simplemente inyectando código malicioso (p. Ej. ¡No puedo creer que olvidé eliminar la línea que registra los datos de la tarjeta de crédito de los clientes, querido señor! ).
Pequeña actualización (6/6/2012)
Los procedimientos almacenados (al menos en Oracle) evitan hacer algo como la entrega continua con tiempo de inactividad cero, ya que cualquier cambio en la estructura de las tablas invalidará los procedimientos y los desencadenantes. Por lo tanto, durante el tiempo que se actualiza la base de datos, la aplicación también estará inactiva. Oracle proporciona una solución para esta denominada Redefinición basada en la edición , pero los pocos DBA que he preguntado sobre esta característica mencionaron que estaba mal implícita y no la incluirían en una base de datos de producción.