La llegada de la nube ha cambiado para siempre la forma en que consumimos software, pasando de tener que instalar una aplicación en nuestro equipo, ha simplemente acceder a un sitio web para tener acceso a toda nuestra información, pero la pregunta clave aquí es, ¿cómo es que una aplicación que vive en la nube, puede albergar múltiples clientes y al mismo tiempo mantener separada la información? Bueno, para resolver esta pregunta tenemos el termino Multi-Tenancy.
as
En Java como en cualquier otro lenguaje de programación, es común encontrarnos con la necesidad de realizar conversión de tipos de datos, sobre todo, aquellos tipos de datos de Entidad que tiene una relación directa con un DTO que utilizamos para enviar los datos del servidor a un cliente o aplicación web, lo que hace que tengamos que convertir la Entidad a DTO para enviarla al cliente y de DTO a Entidad para persistirla en la base de datos, lo cual es una tarea cansada y repetitiva que podemos evitar mediante el uso del patrón Converter.
as
Mediante la anotación @JoinColumn es posible personalizar las columnas que será utilizadas como uniones con otras tablas. Cuando trabajamos con relaciones como @ManyToOne o @OneToOne, es necesario indicarle a JPA como es que tendrá que realizar la unión (JOIN) con la otra Entidad. as
Prácticamente todas las aplicaciones de hoy en día, requiere acceso al menos a una fuente de datos, dichas fuentes son por lo general base de datos relacionales, por lo que muchas veces no tenemos problema en acceder a los datos, sin embargo, hay ocasiones en las que necesitamos tener más de una fuente de datos o la fuente de datos que tenemos puede variar, lo que nos obligaría a refactorizar gran parte del código. Para esto, tenemos el patrón Arquitectónico Data Access Object (DAO), el cual permite separar la lógica de acceso a datos de los Bussines Objects u Objetos de negocios, de tal forma que el DAO encapsula toda la lógica de acceso de datos al resto de la aplicación. as
La llegada de nuevas arquitecturas como SOA o Microservicios han traído grandes ventajas, pero con ello, han surgido nuevas problemáticas que pocas veces se sabe cómo resolver con precisión, uno de estos casos, es identificar cuando un servicio ha dejado de funcionar para dejarle de enviar peticiones, pero por otro lado, identificar el fallo, reportarlo y hacer algo en consecuencia, por suerte, la patrón Circuit Breaker (Corto circuito) permite cerrar la comunicación con un determinado servicio cuando se ha detectado que está fallado. as
Una de las problemáticas más comunes cuando desarrollamos aplicaciones, es diseñar la forma en que la información debe viajar desde la capa de servicios a las aplicaciones o capa de presentación, ya que muchas veces por desconocimiento o pereza, utilizamos las clases de entidades para retornar los datos, lo que ocasiona que retornemos más datos de los necesarios o incluso, tengamos que ir en más de una ocasión a la capa de servicios para recuperar los datos requeridos. as
Una gran parte de las aplicaciones que se construyen hoy en día, requieren de un API para funcionar, dicha API ofrece todos los servicios necesarios para que la aplicación puede interactuar con el Backend y así afectar la información de la base de datos, sin embargo, de esa gran cantidad de aplicaciones que se conectan con APIs, requieren saber exactamente donde está alojado (IP y puerto) cada uno de los servicios que conforman el ecosistema de microservicios, es allí donde entra el Service Discovery pattern para solucionar ese tipo de dependencias. as
Este video es la continuación del video de introducción a al patrón Factory Method. En esta segunda entrega aprenderemos a utilizar el patrón mediante in ejemplo del mundo real, en el cual aprenderemos a crear una aplicación que permite conectarse a más de una base de datos, la cual podrá ser intercambiada por medio de la configuración.
Cuando empecé a estudiar diseño y arquitectura de software, uno de los primeros conceptos con que me encontré fue el de los principios de diseño SOLID.
Me parecieron unas ideas muy interesantes, pero no tan fáciles de aplicar.
Luego aparecieron los patrones de diseño, y todo empezó a tener sentido. Los patrones me dieron estrategias puntuales para resolver problemas específicos en mi código. Mi forma de programar cambió radicalmente luego de conocer los patrones de diseño.
El día hoy estoy muy emocionado por que lanzo mi nuevo curso de Introducción a los patrones de diseño y mi propia plataforma e-leaning, en la cual espero empezar a generar más contenido, el curso lo diseñe para todas aquellas personas que no tiene el tiempo para leer todo un libro de patrones de diseño y necesitan la información lo más compacta posible. as