Al hablar de este tema es muy probable que exista un debate, con relación al manejo de '
Store Procedure' para el acceso a datos dentro de los Servicios, con relación a un proyecto
SOA. Ya que actualmente existe profesionales que son partidarios de los SPs y otros muchos que no. Desde mi punto de vista, he tenido el privilegio que manejar ambos escenarios (
SPs y SQL embebido) y el manejo de los
SPs a nivel de servicios es lo mejor debido a muchos puntos entre los que resaltan:
- Permite segmentar (desacopla) la 'capa de aplicación' (BD) con relación a la 'capa de servicios', permitiendo que exista un equipo/área destinada solo a labores exclusivas de BD (componentes).
- Agiliza el desarrollo, ya que defiendo los parámetros INPUT/OUTPUT del SP, permite que ambos equipos (Integración y BD), puedan trabajar en paralelo y tener todo documentado.
- Facilita el mantenimiento, ya que ante un problema, cambio y/o mejora a nivel de datos, el impacto no requerirá modificar la fuente, solo el SP respectivamente y esto sería mucho más rápido.
Por otro lado, los que están en contra del manejo de
SPs, dirán que es un esfuerzo mayor, para el servicio ya que se añade una capa extra de transformación. En este caso yo respondería, lo mismo dicen para el uso
ESB y al igual que en dicho caso pienso que el sacrificio vale la pena debido a la mayor cantidad de beneficios que consigo trae su manejo.
2 comentarios:
He trabajado en varios proyectos(Oracle, IBM y WSO2) donde se usan SP para los servicios de datos y estoy de acuerdo con su uso por encima del SQL embebido. El nivel de desacoplamiento entre equipos es mayor.
Es correcto ahí uno debe de priorizar el nivel de desacoplamiento que se gana al usar Store Procedure. Así al alterar algo a nivel de BD no impacta al servicio esa es la idea y con esto no se generan versiones innecesarias.
Publicar un comentario