Gracias por el vídeo y las explicaciones, y enhorabuena por el canal. Desde mi punto de vista, completamente personal y bajo la experiencia que tengo, no estoy de acuerdo con sustituir el versionado por ramas con la librería que nos comentas, puede que no te haya entendido bien, por eso escribo. Por lo que comentas, la duplicación de código que al final se puede liar en el proyecto puede ser monumental, hoy hay empresas que tienen actualizaciones muy frecuentes, y sería inviable usar esta librería para el versionado. Sin embargo, si tienes ramas, cuando dichas versiones dejan de ser usadas con borrarlas es suficiente, y si tienen que mantenerla lo haces en su rama correspondiente. Al menos yo lo veo así. Pero estaré encantado de leer tus comentarios.
Hola! Yo creo que aquí podemos entrar en un “eterno debate”. Bajo mi punto de vista mantener diferentes ramas es imposible e ineficiente, por no hablar de que necesitas diferentes endpoints. Por ejemplo si tuvieras dicha web en la nube, supongamos que tienes la web en un contenedor; deberás de configurar uno para cada rama, además del enrutamiento, junto con CI/CD; Para mí, eso no es una opción, es lo mismo a lo que se hacía antiguamente de una rama por cliente, o la típica rama de “release1”, “release2” etc. O por ejemplo si encuentras un bug, tienes que ir aplicándolo a todas las ramas, es muy fácil que se te pueda olvidar una, o que pasa si quitas/cambias una tabla de la base de datos, algo que al usuario final no le afecte, pero cambie un poco tu dominio, necesitas propagar el cambio por miles de branches. Utilizando versioning la duplicación de código es mínima, en el ejemplo que he mostrado si que he duplicado varias cosas, pero podríamos (y debería) haber utilizado herencia y se duplicaría mucho menos a la hora de hacer el mapping. Y con la teoría en mente de que los endpoints realizan una única acción, es muy extraño querer cambiar el funcionamiento de los mismos. Otra regla a tener en cuenta es que cuando creas una nueva versión esta NO puede romper nada que esté funcionando, eventualmente pueden deprecar y quitar versiones, pero no romper las existentes. Con esto en mente un endpoint que es “LeerEmpleado/{id}” deberá siempre leer el empleado por el ID. es mas o menos lo mismo que hace MS, lo puedes ver en su guia: github.com/microsoft/api-guidelines/blob/vNext/Guidelines.md#42-guidelines-for-existing-services-and-versioning-of-services Personalmente trabajo así, en la empresa también, y cero problemas (por ahora, claro). Un saludo. pd: menudo tocho me ha salido 😂
@@NetMentor muchísimas gracias por tu respuesta, lo tendré en cuenta, por ahora profesionalmente no lo he tenido que aplicar, pero me parece otra opción a tener en cuenta, y con las aclaraciones que me has dado más todavía, una cosa más que he aprendido gracias a tu dedicación al canal
Creo que podría mantener el mismo controller, por medio de interfaces y generics cambiar el DTO acorde a la versión....también hay implementaciones multi-tenat.
Pues puede ser, aunuqe no lo tengo claro del todo, ya que hace mucho que no toco EF (desde .net Framework) y ahora hago todo con dapper. Aunque teniendo en cuenta que han re-escrito todo EF para netcore quizá le de otra oportunidad
Excelente como siempre! Consulta, necesito hacer una api para 2 versiones de un producto en el cual las tablas difieren. Pero debe ser trasparente a los clientes... por ejemplo, tengo una tabla employee que una version de la app tiene ciertos campos y en otra version tiene otros campos. Cual seria la solucion ideal? hacer una especie de "union" en los dto que contenga todos los campos de ambas versiones y que si en no hay nada en un campo (porque no se usa en esa version) sea null el valor? Muchas gracias!!
Si he entendido bien la parte de “transparente a los clientes” tu problema es que tienes una única API con un único enpoint, pero internamente coges la información de dos puntos diferentes. Yo sería más partidario de tener dos endpoints que devolvieran diferentes DTOs, pero entiendo que lleva mucho tiempo de desarrollo, así que si, la mejor opción en tu caso es devolver los campos que no estén como null. Un saludo y gracias por apoyar el canal :)
Utilizando un explicit operator es válido generar el DTO? Veo que son herramientas que nos ofrece el lenguaje para hacer el mapper con el operador new. sin embargo, me puedes aclarar si esto rompe con el principio de Inversión de dependencias?
🤔 cierto, el vídeo va más enfocado a event driven design que está ahora tan de moda. Pero es un buen punto el tuyo, quizá debería haber sido menos categórico en ese aspecto, ya que como mencionas en ddd lo que buscamos es almacenar/trabajar dicho modelo de la forma más simple.
Blog: www.netmentor.es/Entrada/differencia-dto-entity
Twitter: twitter.com/NetMentorTW
Este canal esta destinado al exito si o si.
Gracias! me alegro de que te guste el contenido!
Vaya clase tan magistral! Muchas gracias.
Excelente vídeo, muchas gracias por compartir tu conocimiento
Cada vez que escuché "lincado" me dolió..... pero la información es excelente
buena explicación buen Video !
Gracias. Saludos
Gracias por el vídeo y las explicaciones, y enhorabuena por el canal. Desde mi punto de vista, completamente personal y bajo la experiencia que tengo, no estoy de acuerdo con sustituir el versionado por ramas con la librería que nos comentas, puede que no te haya entendido bien, por eso escribo. Por lo que comentas, la duplicación de código que al final se puede liar en el proyecto puede ser monumental, hoy hay empresas que tienen actualizaciones muy frecuentes, y sería inviable usar esta librería para el versionado. Sin embargo, si tienes ramas, cuando dichas versiones dejan de ser usadas con borrarlas es suficiente, y si tienen que mantenerla lo haces en su rama correspondiente. Al menos yo lo veo así. Pero estaré encantado de leer tus comentarios.
Hola!
Yo creo que aquí podemos entrar en un “eterno debate”. Bajo mi punto de vista mantener diferentes ramas es imposible e ineficiente, por no hablar de que necesitas diferentes endpoints.
Por ejemplo si tuvieras dicha web en la nube, supongamos que tienes la web en un contenedor; deberás de configurar uno para cada rama, además del enrutamiento, junto con CI/CD;
Para mí, eso no es una opción, es lo mismo a lo que se hacía antiguamente de una rama por cliente, o la típica rama de “release1”, “release2” etc.
O por ejemplo si encuentras un bug, tienes que ir aplicándolo a todas las ramas, es muy fácil que se te pueda olvidar una, o que pasa si quitas/cambias una tabla de la base de datos, algo que al usuario final no le afecte, pero cambie un poco tu dominio, necesitas propagar el cambio por miles de branches.
Utilizando versioning la duplicación de código es mínima, en el ejemplo que he mostrado si que he duplicado varias cosas, pero podríamos (y debería) haber utilizado herencia y se duplicaría mucho menos a la hora de hacer el mapping.
Y con la teoría en mente de que los endpoints realizan una única acción, es muy extraño querer cambiar el funcionamiento de los mismos.
Otra regla a tener en cuenta es que cuando creas una nueva versión esta NO puede romper nada que esté funcionando, eventualmente pueden deprecar y quitar versiones, pero no romper las existentes. Con esto en mente un endpoint que es “LeerEmpleado/{id}” deberá siempre leer el empleado por el ID.
es mas o menos lo mismo que hace MS, lo puedes ver en su guia: github.com/microsoft/api-guidelines/blob/vNext/Guidelines.md#42-guidelines-for-existing-services-and-versioning-of-services
Personalmente trabajo así, en la empresa también, y cero problemas (por ahora, claro).
Un saludo.
pd: menudo tocho me ha salido 😂
@@NetMentor muchísimas gracias por tu respuesta, lo tendré en cuenta, por ahora profesionalmente no lo he tenido que aplicar, pero me parece otra opción a tener en cuenta, y con las aclaraciones que me has dado más todavía, una cosa más que he aprendido gracias a tu dedicación al canal
wow
Creo que podría mantener el mismo controller, por medio de interfaces y generics cambiar el DTO acorde a la versión....también hay implementaciones multi-tenat.
Gracias por tus videos, son muy instructivos. ¿Tienes en mente subir algun video sobre entity framework?
Pues puede ser, aunuqe no lo tengo claro del todo, ya que hace mucho que no toco EF (desde .net Framework) y ahora hago todo con dapper. Aunque teniendo en cuenta que han re-escrito todo EF para netcore quizá le de otra oportunidad
Excelente como siempre!
Consulta, necesito hacer una api para 2 versiones de un producto en el cual las tablas difieren. Pero debe ser trasparente a los clientes... por ejemplo, tengo una tabla employee que una version de la app tiene ciertos campos y en otra version tiene otros campos. Cual seria la solucion ideal? hacer una especie de "union" en los dto que contenga todos los campos de ambas versiones y que si en no hay nada en un campo (porque no se usa en esa version) sea null el valor? Muchas gracias!!
Si he entendido bien la parte de “transparente a los clientes” tu problema es que tienes una única API con un único enpoint, pero internamente coges la información de dos puntos diferentes.
Yo sería más partidario de tener dos endpoints que devolvieran diferentes DTOs, pero entiendo que lleva mucho tiempo de desarrollo, así que si, la mejor opción en tu caso es devolver los campos que no estén como null.
Un saludo y gracias por apoyar el canal :)
@@NetMentor excelente! Muchas gracias
Utilizando un explicit operator es válido generar el DTO?
Veo que son herramientas que nos ofrece el lenguaje para hacer el mapper con el operador new. sin embargo, me puedes aclarar si esto rompe con el principio de Inversión de dependencias?
si, claro, es totalmente válido genera el dto utilizando implicit operator. De hecho en mi opinion, mucho mejor que automappers y similares.
un saludo
Mmmm por ahi no coincido mucho de que la entidad es una tabla de la BD. En un modelo DDD no seria valido.
🤔 cierto, el vídeo va más enfocado a event driven design que está ahora tan de moda. Pero es un buen punto el tuyo, quizá debería haber sido menos categórico en ese aspecto, ya que como mencionas en ddd lo que buscamos es almacenar/trabajar dicho modelo de la forma más simple.
Pensé que era en Java.
La sintaxis es diferente, pero la idea es la misma en cualquier lenguaje