Patrón de diseño Criteria: Explicado!
Vložit
- čas přidán 24. 01. 2024
- En programación, hay decenas de Patrones de Diseño de Software. Y entre todos ellos hay un gran desconocido: El Patrón Criteria. Gracias a este patrón podemos respetar la O de SOLID en nuestro código y evitar una explosión de métodos.
Curso del Patrón Criteria → bit.ly/curso-criteria
﹤🍍﹥ Codely
├ 🎥 Suscríbete: czcams.com/users/CodelyTV?sub_co...
├ 🔖 Cursos: bit.ly/cursos-codely
└ 👋 Redes sociales:
├ / codelytv
├ / javiercane
├ / rafaoe
├ / codelytv
└ / codelytv - Věda a technologie
El verdadero oro, juyendo a hacer el curso
Los amo, gracias por tanto !
Esto me trajo recuerdos de hace muchos años usando .NET cuando descubrí el patrón Criteria. Usando EntityFramework e implementando el Criteria con métodos genéricos para el filtrado el mismo EF era capaz de generar las consultas de SQL automáticamente... Así que podías mantener tus criterios en el dominio y pasarlos directamente al repositorio en lugar de implementar un método en específico
Buenísimo!! Como siempre ^^
Javi, ¿estás resfriado?
Por fin, un vídeo explicando el criteria porque he visto muchos sitios con un getX(param1, param2, param3, param4....) y con valores seteados por si no viene y con 300 ifs para construir una query... ¡Infernal!
¡Un saludo y gracias!
Correcto, estoy resfriado xD
Hola buenas, podrias hacer algun video relacionado a la automatización de la documentacio, porfa. Estaria muy chulo ver alguno desde vuestro punto de vista. Hay muchas empresas que fallan en este tema, para la gente que entra nueva al proyecto. Y esto seria un puntazo. Gracias
yo le he encontrado un gran problema a este patron a nivel de base de datos... bien sabido es que las entidades de dominio nunca serán del todo parecidas en cuanto a campos y estructura a las entidades de la base de datos, por lo que en la mayoría de los casos será necesario hacer un mapeo entre entidades... el problema ocurre cuando se intenta aplicar este patrón de specification a nivel de dominio. El patrón specification se aplicará en base a la estructura de las entidades de dominio... pero a la hora de mapear estas especificaciones a la base de datos? chocará con que algunos campos no son llamados del mismo modo o de plano ciertas entidades no tienen la misma estructura.
Hacer el mapeo para los specifications entre dominio y base de datos es bastante laborioso (dependiendo del orm/odm que se use) y realmente no he encontrado una alternativa.
Me gustaría saber sí es que uds ya se han topado con este problema o cómo se les ocurre solucionarlo?
Tú eres responsable de la implementación, por lo que tienes control al 100% de cómo aplicar cada criterio. El repositorio junto con los criterios únicamente sirven como contrato para que el invocador pueda hablarle al repositorio en lenguaje del dominio, pero la implementación (que sería de capa de infraestructura) puede mapear esos criterios a como lo necesites
Hola, estoy trabajando con un proyecto bastante antiguo de PHP con Symfony 1x 😨, y que utiliza Propel como ORM… y vaya sorpresa.. usa Criteria’s y lo mejor ..asocio muchísimo lo que nos explican en vuestro vídeo con lo que hacen en propel. No entiendo porque dejo de usarse y fue remplazado por Doctrine?… la verdad le estoy cogiendo bastante gusto a este ORM
Una duda, en el Criteria.or() suponiendo que este retorne un objeto OrCriteria cuya implementación de meetCriteria(), sea iterar primero usando el criteria1, luego iterar usando el criteria2 y luego añadiendo elementos del criteria2 al resultado de criteria1 si estos no existen... suponiendo que son 50 productos, 12 nuevos, 10 prime, el resultado serían 22 productos, pero cuantas iteraciones se estarían realizando?
criteria1 realiza 50 y retorna 12, no?
criteria2 también 50 y retorna 10
luego se iterarian 10 veces para ver si el producto existe en el resultado de criteria1, llamando a un result1.contains() por ejemplo... esto no estaría realizando 10 x 12 = 120 iteraciones devolviendo 22 productos???
me gusta mucho el theme que usan, de casualidad no tendran una extension para vscode?
Pues yo el and y el or lo implementaría como otro criteria que se instancie con un constructor que reciba dos criterias a comparar, asi puedes construir todas las combinaciones posibles y simplifica delegando responsabilidades
Buenas, ¿qué opináis crear un dsl (agnóstico de la base de datos) en vez de criteria??
El Criteria no viene a ser nada más que una forma de representar ese DSL con objetos, así que +1!
es el patron que usaba/usa hibernate? lo dejé de usar hace mucho por eso no estoy seguro.
Lo veo "útil" para cosas livianas en memoria, traer toda la db a memoria para filtrar no sirve
Buena explicando!, una pregunta, que fuentes y tema usan?👀
Una pregunta, estoy trabajando en una start up donde la velocidad de aprendizaje y accion tambien debe ser rapida, algunos conceptos me cuestan pillarlos a la primera. Dentro de codely hay algun chat con vosotros de casos en concreto para resolver dudas?
@@DryadRoot obviamente pagando, la cuestión es aprender
Básicamente un eloquent chiquito?
Esta bueno, aunque a veces, en Java al menos, no es mágico, porque el armado programático de las queries muy grandes con los CriteriaBuilder y Predicates suele perder legibilidad en el código y muchas veces se termina usando una sintaxis "mas sql" por decirlo de alguna manera con JPQL en repositorios JPA. Porque todos entendemos muy rápido SQL, es universal para todos los que programamos, ahora leer 50 lineas de un armado programático de una query no es tan fácil.
Soy el primero,
saludos desde México
Saludoooos!!
No he visto nunca que se use así el patrón repository
Y te convence? 😊
no entiendo porque siempre me siento tan perdido escuchando sus videos, es como si fuera contenido solo para DIOSES
¿Con el criteria como DTO no estáis perdiendo la lógica de los filtros de vuestro dominio y delegándola a la capa de infraestructura? Al ser un DTO genérico, por el dominio podrían pasar filtros que no corresponden al Producto y hasta no llegar a la implementación no sabríamos que son incorrectos, es decir, el dominio los da por válidos cuando no lo son. Entiendo que la lógica de filtros sí debería ser parte del dominio, como en el caso del Criteria como filtro.
No...
Como arquitecto de software, sigo viendo desvíos en cuanto a la teoría y las definiciones incorrectas que dan.
Ejemplo: En 0:27 mencionan que usar interfaces nos da el beneficio del Dependency Inversion Principle.
"What the Dependency Inversion Principle does not refer to is the simple practice of abstracting dependencies through the use of interfaces (e.g. MyService → [ILogger ⇐ Logger]). - Robert Martin"
Si bien las interfaces desacoplan un componente del detalle de implementación específico de la dependencia, no invierte la relación entre el consumidor y la dependencia (por ejemplo, [MyService → IMyServiceLogger] ⇐ Logger)."
estas confundido bro
ok, entonces di xq @@juanpablodiazalbarracin7182
@@juanpablodiazalbarracin7182 Cité la fuente, el maestro Robert Martin. Cité el error en el momento exacto del video.
Yo también puedo decir que estás equivocado, o que tu vida está mal encaminada... Pero si no te doy los argumentos, mi comentario no sirve de nada y no deja de ser una opinión.
Saludos.
Lo que te has perdido @argentobeach es que ProductRepository es del dominio y por tanto el ejemplo es [SearchUseCase → ProductRepository] ⇐ MySQLProductRepository . El patrón Repository por definición implica que haces la inversión de dependencia.
Quiten a las personas de la pantalla, venimos a ver código 😡
Kyc otaku
Les gusta el protagonismo lol
Ese es el estilo de sus videos, así que no se puede pedir un cambio.
Durante todo el vídeo intentamos ubicarnos en la parte de la pantalla que permita ver todo el snippet de código que mostramos. Por ejemplo en este mismo vídeo se puede ver esto en el minuto 4:52
Si mostramos nuestras caras en los vídeos no es porque nos guste el protagonismo. Es porque nos gusta darle un toque humano y porque creemos que la comunicación no verbal es un apoyo que ayuda a reforzar ciertos mensajes y aportar claridad en las explicaciones.
Personas como tú quitan las ganas de hacer cosas, lárgate a otro lado si no te gusta.