Principios SOLID 👇 ruclips.net/p/PLy4xaLa5b6WOPNB30QIhH8hTfwLa19rIG En el próximo video crearemos una aplicación desde 0 usando Clean Architecture. Suscríbete para no perdértelo!
Creo que es la mejor explicación corta que he encontrado, cada frase cuenta, como dijo el dermatólogo: AL GRANO. Te ganaste un seguidor. En una semana he ido leyendo y recopilando información y llegar a este video me ha servido bastante y viene a complementar mucho de lo que he leído. Gracias 🤜🏻🤛🏻
Me he visto este video varias veces y tomó mucho sentido cuando entendí los principios SOLID que explicas en otros videos. Muchas gracias por compartir tu conocimiento.
Gracias a ti Cesar. Si no has hecho aún el curso de Clean Architecture te recomiendo que lo hagas para poner en práctica todos los conocimientos: ruclips.net/p/PLy4xaLa5b6WPoXzJIwbrjQvbT5sPDJy3M Saludos!
Muy bien explicado que están en este video los conceptos de Clean Architecture. Como dato curioso, muy interesante el fondo de audio usado. Me hizo revisar varias veces a ver si no tenía el Call of Duty abierto en background jajaja
No me queda claro como implementarias un caso de uso que debe acceder a datos, in que este dependa del acceso a esos datos. Me parece que lo mas logico seria tener un componente que maneje el acceso a datos y otro que lo consuma con lo cual pasa a depender de él. Con lo poco frecuente que es el cambio de BD, no me parece tenga sentido complejizar el proyecto, generando una infinidad de metodos para obtener entidades de la db. Por otro lado, traer datos desde la DB para procesarlos y luego enviarlos devuelta, es infinitamente mas costoso que operar directo en la db.
Gracias por tu comentario, voy a intentar responderte a todos los puntos: En Clean Architecture, los casos de uso no dependen directamente del acceso a datos. En su lugar, definen una interfaz que describe las operaciones necesarias. La implementación de esta interfaz se hace en la capa de datos o infraestructura, y la interfaz pertenece a la capa de dominio. Esto es la inversión de la dependencia. Así, puedes cambiar la implementación sin afectar la lógica de negocio. Para esto se suele usar el patrón repository. Aunque los cambios en la base de datos no sean frecuentes, esta separación facilita pruebas y mantenimiento. No se reduce solo base de datos, es cualquier dependencia a un framework, una API o una librería. Cualquier cosa que sea externa a tu sistema. La idea es proteger la lógica de negocio de esos detalles. En términos de rendimiento, es cierto que puede ser más costoso traer datos de la base de datos y luego procesarlos. Sin embargo, en la práctica, Clean Architecture permite optimizar esto mediante estrategias como el uso de consultas específicas (CQRS) y técnicas de caching (entiendo que estas hablando de desarrollo backend). La arquitectura no prescribe que siempre debas traer todos los datos a la capa de negocio para procesarlos, sino que te da la flexibilidad de estructurar tu código de manera que puedas aplicar diferentes estrategias según las necesidades de rendimiento. No digo que siempre haya que usar Clean Architecture. Depende de muchos factores, de los cuales hablo en este video: ruclips.net/video/ngPJ9_jMv8U/видео.html Un saludo!
![Curso de CLEAN ARCHITECTURE (Arquitectura Limpia) en Swift [Parte 1]](/img/1.gif)
Principios SOLID 👇
ruclips.net/p/PLy4xaLa5b6WOPNB30QIhH8hTfwLa19rIG
En el próximo video crearemos una aplicación desde 0 usando Clean Architecture.
Suscríbete para no perdértelo!
excelentisima explicacion, Jefe. te has ganado un seguidor!
Muchas gracias y bienvenido al canal!
Saludos!
muy bien explicado, muchas gracias
La edición es otro nivel tío! Vamos a por más 🔥🔥
Poco a poco vamos mejorando
Gracias hermanito!
excelente video. muy interesante, la verdad. Eres de los pocos canales que hay de estos temas en español actualizados😃
Muchas gracias Lucas!
Te recomiendo dividir los video en capítulos, eso ayuda a las búsquedas en google y bing.
Me parece muy buena idea! Muchas gracias por el feedback!
Creo que es la mejor explicación corta que he encontrado, cada frase cuenta, como dijo el dermatólogo: AL GRANO. Te ganaste un seguidor. En una semana he ido leyendo y recopilando información y llegar a este video me ha servido bastante y viene a complementar mucho de lo que he leído. Gracias 🤜🏻🤛🏻
Muchas gracias por tus palabras y por apoyo!
Me alegra mucho que te haya ayudado.
Saludos!
Me he visto este video varias veces y tomó mucho sentido cuando entendí los principios SOLID que explicas en otros videos. Muchas gracias por compartir tu conocimiento.
Gracias a ti Cesar. Si no has hecho aún el curso de Clean Architecture te recomiendo que lo hagas para poner en práctica todos los conocimientos: ruclips.net/p/PLy4xaLa5b6WPoXzJIwbrjQvbT5sPDJy3M
Saludos!
@@SaidRehouni Gracias, en esas ando, un contenido muy valioso 🤩
Estoy en proceso de ser iOS Engineer, ojalá hubiese encontrado tu canal antes, no hubiese andado divagando mucho tiempo.
Muchas gracias Guillermo! Pronto haré más contenido para los que estáis empezando.
Saludos!!
Está muy bien explicado, se lo pasaré a un par de juniors de la ofi, muchas gracias!
Muchas gracias a ti por el apoyo y por compartir!
Saludos
Exelente explicación
Muchas gracias!
Me gusta cómo expones información compleja de forma muy clara. Me quedo por el canal para ver si vienen nuevos videos pronto! Un saludo
Muchas gracias por el apoyo!
Saludos!
Ahora me queda mas claro todo! sigue subiendo este tipo de videos!
Muchas gracias por el apoyo Marco Alonso! ME alegra que te haya resultado útil
Muchas gracias excelente contenido 👌🏻👌🏻👌🏻
Gracias a ti Richard!
Saludos!
Increíble vídeo! Me quedó bastante claro. Voy a seguir mejorando como iOS Engineer gracias a tus vídeos.
Muchas gracias! Me alegra mucho que te haya ayudado.
Saludos!
Muy bien explicado que están en este video los conceptos de Clean Architecture. Como dato curioso, muy interesante el fondo de audio usado. Me hizo revisar varias veces a ver si no tenía el Call of Duty abierto en background jajaja
Jajaja es un mensaje subliminal..
Muchas gracias!
@@SaidRehouni Está muy bien como explicas. Sigue así mismo.
Excelente explicación. Sencilla y directa.
Muchas gracias Cesar!
Muy bien explicado todo, gracias por la info ❤️
Muchas gracias Adrian!
Gracias por el video, explicas muy bien 👍.
Muchas gracias!
Saludos
excelente video!
No me queda claro como implementarias un caso de uso que debe acceder a datos, in que este dependa del acceso a esos datos. Me parece que lo mas logico seria tener un componente que maneje el acceso a datos y otro que lo consuma con lo cual pasa a depender de él. Con lo poco frecuente que es el cambio de BD, no me parece tenga sentido complejizar el proyecto, generando una infinidad de metodos para obtener entidades de la db. Por otro lado, traer datos desde la DB para procesarlos y luego enviarlos devuelta, es infinitamente mas costoso que operar directo en la db.
Gracias por tu comentario, voy a intentar responderte a todos los puntos:
En Clean Architecture, los casos de uso no dependen directamente del acceso a datos. En su lugar, definen una interfaz que describe las operaciones necesarias. La implementación de esta interfaz se hace en la capa de datos o infraestructura, y la interfaz pertenece a la capa de dominio. Esto es la inversión de la dependencia. Así, puedes cambiar la implementación sin afectar la lógica de negocio. Para esto se suele usar el patrón repository.
Aunque los cambios en la base de datos no sean frecuentes, esta separación facilita pruebas y mantenimiento. No se reduce solo base de datos, es cualquier dependencia a un framework, una API o una librería. Cualquier cosa que sea externa a tu sistema. La idea es proteger la lógica de negocio de esos detalles.
En términos de rendimiento, es cierto que puede ser más costoso traer datos de la base de datos y luego procesarlos. Sin embargo, en la práctica, Clean Architecture permite optimizar esto mediante estrategias como el uso de consultas específicas (CQRS) y técnicas de caching (entiendo que estas hablando de desarrollo backend). La arquitectura no prescribe que siempre debas traer todos los datos a la capa de negocio para procesarlos, sino que te da la flexibilidad de estructurar tu código de manera que puedas aplicar diferentes estrategias según las necesidades de rendimiento.
No digo que siempre haya que usar Clean Architecture. Depende de muchos factores, de los cuales hablo en este video: ruclips.net/video/ngPJ9_jMv8U/видео.html
Un saludo!
En terminos generales, estoy de acuerdo con clean, no coincido en que valga la pena en el acceso a datos en particular.