Captura de pantalla 2014-09-06 a la(s) 11.40.21

En los 90, en segundo curso de la carrera de informática, aprendí programación C++. Digamos que fue una “revelación” en cuanto a la forma de pensar y de implementar un programa, mediante objetos, que pretendían ser una “imitación” de los objetos del mundo real.

Como es sabido los objetos tienen atributos, variables que conforman su estado, y también, indisolublemente unidos, comportamiento. Mediante este comportamiento, implementando con métodos, se define lo que el objeto es capaz de hacer.

Esto es un enfoque totalmente distinto a lo que había hasta ese momento: el paradigma de la programación estructurada, donde los datos van por un lado y el comportamiento va por otro (al contrario de un objeto).

Por desgracia, en las grandes empresas, la velocidad de adopción de cambios de paradigma es muy lenta. Al día de hoy, muchas de ellas, sobre todo en el sector financiero, sus lógicas de negocio se basan en programación estructurada.

Incluso allí donde ha podido llegar la programación orientada a objetos, basado en Java normalmente, tenemos unos escenarios que no son puros en su orientación a objetos. Me refiero sobre todo a las bases de datos, que siguen siendo del tipo relacional.

mapeo objeto relacional

Debido a todo esto, un programador de lógicas de negocio (aunque lo haga en Java) desarrolla con orientación a objetos pero  a la hora de persistir los datos de estos objetos tiene que estructurar la información en un formato totalmente diferente, para que encaje en las tablas y columnas de las bases de datos. Es un esfuerzo muy importante el cambiar totalmente esta estructura cada vez que se hace una operación de persistencia… es como si hablásemos en Español y escribiésemos en inglés.

Así pues, en cuanto a la persistencia, si trabajamos con objetos y bases de relacionales tenemos un trabajando bastante importante en hacer el mapeo. Pero ¿que pasa cuando ya no tenemos una base de datos relacional? ¿Qué sucede por ejemplo, cuando nuestra persistencia no se basa en columnas y en tablas sino en documentos JSON?.

La “CRUD” de las aplicaciones de gestión

Si digo que una gran parte de las operativas de una aplicación típica de gestión son las Altas, Bajas, Consultas y Acualizaciones (CRUD) no descubro en absoluto la pólvora. Sin embargo, esto nos lleva a una reflexión muy interesante cuando pensamos en la implementación de una aplicación de este tipo.

Precisamente los servicios tipo REST, todo un estándar de facto actualmente, definen cuatro operaciones que se corresponden con las CRUD antes mencionadas:

  • Alta – Create : PUT
  • Baja – Delete: DELETE
  • Modificación – UPDATE : POST
  • Consulta – READ: GET

Podemos entonces decir que en una aplicación típica de gestión comercial, el grueso de la lógica de una entidad de negocio como un “cliente”, un “producto” o un “pedido”.

Como resultado de este enfoque a REST, nos encontramos con que los métodos más importantes de nuestros objetos, en algunas ocasiones quizás los únicos métodos de negocio que tengamos, ya están predefinidos. Tendremos por lo tanto el alta, baja, modificación y consulta de la entidad de negocio o lo que es lo mismo el create, delete, update y read de nuestro recurso.

Recapitulando

Si recapitulamos sobre lo que hemos visto, tendremos entonces:

  • Una aplicación típica de gestión, cuyas operaciones más importante son las CRUD
  • El estándar de implementación de servicios es REST (que sigue el enfoque CRUD) que define el comportamiento de nuestros objetos
  • Los nuevos repositorios de información, en la línea de noSQL, se pueden basar en documentos (documentos JSON por ejemplo)

Si lo juntamos todo, y lo implementamos en forma de interfaces, tendríamos los siguiente.

Así es como estoy enfocando actualmente el desarrollo de webs de servicios REST. ¿Qué opinas?

 

 

 

 

Anuncios