Conoce mi curso de Arquitecturas Limpias 👉platzi.com/arquitecturaslimpias Si no te tienes suscripción en Platzi, usa mi enlace de afiliado: platzi.com/l/manuelzapata/
Hola Manuel! Te conocí por los NullPonters. Sos la información que estaba buscando hace mucho, por lo general te hablan de lenguajes, frameworsk, librerías y demás cosas del estilo pero lo tuyo es la base. Felicitaciones!
Como se implementaría una aplicación ejemplo con windows form utilizando la lógica de negocio desde el servidor? Es decir si tengo le proyecto en 3 capas con sus dll se puede implementar igual o se tiene que hacer desde 0? se necesita un programa adicional?
Me acabo de suscribir a tu canal me parecio increiblemente nutritivo el contenido te consulto libros y recomendaciones para aprender sobre este modelado respecto a la logica de negocios ... desde ya un suscriptor mas atento a tu contenido !!
Acabo de descubrir tu canal es una mina que me encontre. Estoy iniciando con la programación soy autidacta y quiero aclarar estos temas o alguien de la comunidad que lo hiciera. Pasa que siempre he desarrollado aplicaciones CRUD y nunca he visto esto de "logica de negocios", "regla de negocios", "core" en la practica, y ahora mas que mencionas logica de "negocio en lado del cliente" ya me perdí. Entonces ¿que es realmente la logica de negocios?, ¿En que parte de nuestra aplicación se integra?. Gracias.
Hola, me gustó mucho el video, pero aun tengo dudas sobre la logia de negocio y como estructurar todo de manera correcta ¿Tienes algún libro, blog o video que me ayude? te lo agradecería muchísimo 😊
Revistate un libro de Martin Fowler que se llama "Patterns of Enterprise Application Architecture". Tiene varios capitulos dedicados a lógica de negocio.
Gracias Manuel es un tema que disipa muchas dudas, por ejemplo en algunos casos se maneja la misma lógica de negocio en el cliente se repite a partir del concepto de ahorrarnos una petición al servidor pero esto está realizando dos validaciones, que piensas de ese contexto?
Si la lógica de negocio en el cliente, está limitada solo a validaciones, yo creo que está bien. Eso mejora la usabilidad de la aplicación. Sin embargo, lo ideal es validar también en el servidor (así el cliente ya haya validado). La razón principal es seguridad. Los browsers dan mucha flexibilidad a usuarios malintencionados. Basta con llamar directamente el servicio o deshabilitar el JavaScript en el navegador para que las validaciones no se apliquen.
Hola, buen día! Por ejemplo en casos como Angular (y apps) donde el mismo framework te permite construir la aplicación junto con -casi- toda la lógica de negocios y -a veces- solo delegar al servidor el resguardo de los datos ¿vale la pena retirar esta responsabilidad al cliente para enviarla al servidor? se entiende que en caso de tener app y web se tendría que replicar esta funcionalidad, pero considero que se gana en performance y en consumos al servidor. ¿Que opinan? no soy experto y podría no estar viendo algo y me gustaría que me ayuden a ampliar mi perspectiva del escenario.
Gracias Manuel, excelente vídeo. Tengo un dilema con respecto a que tan insegura podría ser una aplicación si su lógica de negocio esta en el cliente. Digamos en una aplicación desarrollada por ejemplo en Angular.
Depende mucho del despliegue y como manejes ciertas cosas a nivel de aplicación. Por ejemplo, si por error subes los archivos .map a producción, dejas tu código expuesto. Si usas el session o el local storage, y todo lo pones en texto plano, también queda expuesto.
Hola manuel, estoy desarrollando una aplicación en Laravel y utilizó su motor de plantillas Blade Eso quiere decir que toda mi lógica de negocio está en el cliente?
Yo creo que sí Diego. Especialmente en el ámbito web. Los browsers son herramientas muy potentes que facilmente dejan expuesta tu aplicación. Por ejemplo, se deshabilita el JavaScript y cualquier validación que tengas con este lenguaje, ya no funciona.
Excelente video Manuel, gracias por compartir tus conocimientos. Una pregunta: para una aplicación de escritorio utilizando C# y windows forms, cómo me aconsejas hacer la conexión entre mi capa de presentación y la lógica que está en otra pc que brinda servicios de servidor? Gracias.
Con aplicaciones de escritorio, las opciones son mayores. Pero creo que me iría con un API REST clásico. Facilita la interoperabilidad si algún día una aplicación web se conecta a ese servicio.
Creo que existe un escenario posible para utilizar un poco de lógica en ambos lados y sería aplicada en backends que son dinámicos. En otro sentido una lógica abstracta de negocio. En el que varios clientes pueden consumir esa lógica aplicando diferentes conceptos de negocio de forma personalizada e independiente, pero basándote en el mismo sistema de acceso de datos. Véase en un sistema de blog dinámico, etc. ¿Tú qué opinas?
Manuel una pregunta que recomendarías en este caso tengo una solución con n proyectos uno es para la APIREST, otro con las clases dto etc, otro con los Repositorios, otro para una aplicación de escritorio para la aplicación de escritorio recomiendas consumir la api o los repositorios, cabe decir que la api utiliza el proyecto de repositorio. No se si me expliqué bien
Sin tener full contexto de tu problema, yo te recomendaría consumir el API. Así tienes todas las validaciones de seguridad. Además, centralizas todos los llamados. Eso te va a facilitar mucho los cambios. Saludos Jose!
Las validaciones de seguridad se hacen el la capa API o en la de logica de negocio? O se reparten las validaciones segun el tipo? por ejemplo el api hago que valide mal formato o datos incompletos, los numeros no cumplen un rango, ect
Hola Manuel, buen video. ahorita prácticamente todos los desarrollos se hacen bajo la arquitectura cliente - servidor, entonces lo recomendable es que la lógica de negocio siempre este en el servidor?
Muy buen video! Muchas gracias. Tengo una pregunta: cuando el API expone los recursos hacia el cliente, es normal tener unos "transfer objects" repetidos en cada lado para facilitar la comunicación. En C#, por ejemplo, el cliente mapea esos objetos a ViewModels y luego los pasa a la vista. Es recomendable devolver el ViewModel desde el servidor para evitar ese último paso? Al principio podríamos pensar que un servicio puede servir para varias vistas, pero eso sucede en muy pocos casos. En otras palabras: el API devuelve justo lo que necesita la vista o los recursos para que se construya del lado del cliente?
En mi experiencia Leo, yo prefiero devolver transfer objects con la información precisa que necesita la vista, y ya que la vista se encargue de convertir a view-models. No devolvería el view model directamente desde el servidor porque es muy fácil cruzar la línea de meter la lógica de presentación en el servidor. Por ejemplo, colores o estilos (lo he visto). Otra alternativa que tenés es tomar la decisión consciente de acoplar un controlador a una vista. Lo que Fowler llama un Page Controller: martinfowler.com/eaaCatalog/pageController.html Allí ya tendrías los controladores organizados por página o vista, y no por dominio u otro concepto.
Hola Manuel, tú diferencias entre lógica de negocio y dominio? Me surge una duda respecto a eso. Si la aplicación (Android, por ejemplo) recibe datos de una Api, las entidades y los modelos forman parte del dominio? Se debe hacer robusta esa parte o mantenerla lo más simple posible (tal vez una clase que haga las peticiones y ya)? Gracias por compartir tus conocimientos 😁
Hola Marcelo. Normalmente las entidades y modelos hacen parte del dominio del problema. Qué tan robusta sea depende de qué tanta responsabilidad le quieras dar al cliente. Por ejemplo, hay personas que mandan toda la lógica de negocio al backend y dejan la app recibiendo y enviando DTOs. Saludos!
Cuando se derrolla una app movil en dónde hay que tener en cuenta que el usuario piede no estar conectado a un Internet, sería conveniente que la app contemple ese escenario y poder utilizar la app aun sin conexión a Internet. En todo caso yo casi siempre utilizo el peor escenario.
No se por experiencia en un proyecto de un software contable la lógica de facturación que era calcular el total de una factura cuando se estaba creando el resultado era unos retardos por que cada ves que calculaba el subtotal de un producto hacía una petición servidor la experiencia de usuario era pobre entonces se recomendó que esa lógica de calcular el total estuviera en el cliente entonces se redujo mucho las peticiones de servidor y experiencia de usuario mejoro no sense ai esta logica es una parts De logica De negocio
Sí, eso haría parte de la lógica de negocio. Obviamente cada caso tiene sus particularidades, pero en las condiciones apropiadas lo ideal sería no duplicar la lógica de negocio en múltiples clientes.
La logica de formato de datos, ejemplo escritura de precios con decimal o miles, estructura de fechas, etc deberia estar en el cliente o servidor ?, Excelente video, muchas gracias.
Conoce mi curso de Arquitecturas Limpias
👉platzi.com/arquitecturaslimpias
Si no te tienes suscripción en Platzi, usa mi enlace de afiliado: platzi.com/l/manuelzapata/
Excelente vídeo
Visto en 03/03/2021
11:45. Es cierto que es buen hábito realizar la validación de datos. Pero a mi parecer también debería estar del lado del servidor (por las dudas)
El vídeo más claro que encontré, muchas gracias
Excelente video Manuel! Eternamente agradecido!!
que video mas estupendo, muy bien explicado jjaja muy muy bueno👍🏽
Gracias Carlos!!
Muy deacuerdo con tus consejos en tu video gracias por haberlo expuesto aqui.
Excelente Manuel ! Creo que este vídeo le acaba de cambiar la vida a mi yo del futuro, gracias !!
Buenísimo! 🤩
Increíble vídeo, gracias por compartir tus conocimientos. Estoy aprendiendo mucho contigo!
Manuel muchas gracias por los vídeos es uno de los mejores canales en español de desarrollo de software. Gracias x El esfuerzo.
Gracias por esas palabras, Julio. Se hace lo mejor que se puede.
@@ManuelZapata pura vida. Ojalá un día te hagas un live para conversar
Excelente explicación
Hola Manuel! Te conocí por los NullPonters. Sos la información que estaba buscando hace mucho, por lo general te hablan de lenguajes, frameworsk, librerías y demás cosas del estilo pero lo tuyo es la base. Felicitaciones!
Genial Sergio! Esa era un poco la idea del canal. Salirnos un poco de los tutoriales y profundizar en aspectos que poco se tocan.
¡Muchas gracias! Buen contenido
Como se implementaría una aplicación ejemplo con windows form utilizando la lógica de negocio desde el servidor? Es decir si tengo le proyecto en 3 capas con sus dll se puede implementar igual o se tiene que hacer desde 0? se necesita un programa adicional?
Me acabo de suscribir a tu canal me parecio increiblemente nutritivo el contenido te consulto libros y recomendaciones para aprender sobre este modelado respecto a la logica de negocios ... desde ya un suscriptor mas atento a tu contenido !!
Gracias Manuel. Has respondido muchas de mis dudas 👍😁
Que bueno Felix!
Acabo de descubrir tu canal es una mina que me encontre. Estoy iniciando con la programación soy autidacta y quiero aclarar estos temas o alguien de la comunidad que lo hiciera. Pasa que siempre he desarrollado aplicaciones CRUD y nunca he visto esto de "logica de negocios", "regla de negocios", "core" en la practica, y ahora mas que mencionas logica de "negocio en lado del cliente" ya me perdí. Entonces ¿que es realmente la logica de negocios?, ¿En que parte de nuestra aplicación se integra?. Gracias.
Excelente explicación..! Excelente... Felicitaciones
Hola, me gustó mucho el video, pero aun tengo dudas sobre la logia de negocio y como estructurar todo de manera correcta ¿Tienes algún libro, blog o video que me ayude? te lo agradecería muchísimo 😊
Revistate un libro de Martin Fowler que se llama "Patterns of Enterprise Application Architecture". Tiene varios capitulos dedicados a lógica de negocio.
Gracias Manuel es un tema que disipa muchas dudas, por ejemplo en algunos casos se maneja la misma lógica de negocio en el cliente se repite a partir del concepto de ahorrarnos una petición al servidor pero esto está realizando dos validaciones, que piensas de ese contexto?
Si la lógica de negocio en el cliente, está limitada solo a validaciones, yo creo que está bien. Eso mejora la usabilidad de la aplicación.
Sin embargo, lo ideal es validar también en el servidor (así el cliente ya haya validado). La razón principal es seguridad. Los browsers dan mucha flexibilidad a usuarios malintencionados. Basta con llamar directamente el servicio o deshabilitar el JavaScript en el navegador para que las validaciones no se apliquen.
Hola, buen día! Por ejemplo en casos como Angular (y apps) donde el mismo framework te permite construir la aplicación junto con -casi- toda la lógica de negocios y -a veces- solo delegar al servidor el resguardo de los datos ¿vale la pena retirar esta responsabilidad al cliente para enviarla al servidor? se entiende que en caso de tener app y web se tendría que replicar esta funcionalidad, pero considero que se gana en performance y en consumos al servidor. ¿Que opinan? no soy experto y podría no estar viendo algo y me gustaría que me ayuden a ampliar mi perspectiva del escenario.
Gracias Manuel, excelente vídeo. Tengo un dilema con respecto a que tan insegura podría ser una aplicación si su lógica de negocio esta en el cliente. Digamos en una aplicación desarrollada por ejemplo en Angular.
Depende mucho del despliegue y como manejes ciertas cosas a nivel de aplicación.
Por ejemplo, si por error subes los archivos .map a producción, dejas tu código expuesto. Si usas el session o el local storage, y todo lo pones en texto plano, también queda expuesto.
Hola manuel, estoy desarrollando una aplicación en Laravel y utilizó su motor de plantillas Blade
Eso quiere decir que toda mi lógica de negocio está en el cliente?
Está en el servidor porque PHP se ejecuta del lado del servidor. Si pusieras lógica en JavaScript, ahí si la tendrías del lado del cliente.
Gracias Manuel! Estuvo súper. Por ahí sigo con la duda si las validaciones de datos serían necesarias hacerlas también en el servidor? Que piensas tú?
Yo creo que sí Diego. Especialmente en el ámbito web. Los browsers son herramientas muy potentes que facilmente dejan expuesta tu aplicación. Por ejemplo, se deshabilita el JavaScript y cualquier validación que tengas con este lenguaje, ya no funciona.
@@ManuelZapata Gracias Manuel!! Ya con mucha mas confianza argumento lo tengo claro. Gracias por responder! 🖒
Excelente video Manuel, gracias por compartir tus conocimientos. Una pregunta: para una aplicación de escritorio utilizando C# y windows forms, cómo me aconsejas hacer la conexión entre mi capa de presentación y la lógica que está en otra pc que brinda servicios de servidor? Gracias.
Con aplicaciones de escritorio, las opciones son mayores. Pero creo que me iría con un API REST clásico. Facilita la interoperabilidad si algún día una aplicación web se conecta a ese servicio.
Creo que existe un escenario posible para utilizar un poco de lógica en ambos lados y sería aplicada en backends que son dinámicos. En otro sentido una lógica abstracta de negocio. En el que varios clientes pueden consumir esa lógica aplicando diferentes conceptos de negocio de forma personalizada e independiente, pero basándote en el mismo sistema de acceso de datos. Véase en un sistema de blog dinámico, etc. ¿Tú qué opinas?
Manuel una pregunta que recomendarías en este caso tengo una solución con n proyectos uno es para la APIREST, otro con las clases dto etc, otro con los Repositorios, otro para una aplicación de escritorio para la aplicación de escritorio recomiendas consumir la api o los repositorios, cabe decir que la api utiliza el proyecto de repositorio. No se si me expliqué bien
Sin tener full contexto de tu problema, yo te recomendaría consumir el API. Así tienes todas las validaciones de seguridad. Además, centralizas todos los llamados. Eso te va a facilitar mucho los cambios. Saludos Jose!
@@ManuelZapata excelente muchas gracias
Las validaciones de seguridad se hacen el la capa API o en la de logica de negocio? O se reparten las validaciones segun el tipo? por ejemplo el api hago que valide mal formato o datos incompletos, los numeros no cumplen un rango, ect
Hola Manuel, buen video. ahorita prácticamente todos los desarrollos se hacen bajo la arquitectura cliente - servidor, entonces lo recomendable es que la lógica de negocio siempre este en el servidor?
Sería lo ideal, Enrique.
Muy buen video! Muchas gracias. Tengo una pregunta: cuando el API expone los recursos hacia el cliente, es normal tener unos "transfer objects" repetidos en cada lado para facilitar la comunicación. En C#, por ejemplo, el cliente mapea esos objetos a ViewModels y luego los pasa a la vista. Es recomendable devolver el ViewModel desde el servidor para evitar ese último paso? Al principio podríamos pensar que un servicio puede servir para varias vistas, pero eso sucede en muy pocos casos. En otras palabras: el API devuelve justo lo que necesita la vista o los recursos para que se construya del lado del cliente?
En mi experiencia Leo, yo prefiero devolver transfer objects con la información precisa que necesita la vista, y ya que la vista se encargue de convertir a view-models.
No devolvería el view model directamente desde el servidor porque es muy fácil cruzar la línea de meter la lógica de presentación en el servidor. Por ejemplo, colores o estilos (lo he visto).
Otra alternativa que tenés es tomar la decisión consciente de acoplar un controlador a una vista. Lo que Fowler llama un Page Controller: martinfowler.com/eaaCatalog/pageController.html
Allí ya tendrías los controladores organizados por página o vista, y no por dominio u otro concepto.
Hola Manuel, tú diferencias entre lógica de negocio y dominio? Me surge una duda respecto a eso. Si la aplicación (Android, por ejemplo) recibe datos de una Api, las entidades y los modelos forman parte del dominio? Se debe hacer robusta esa parte o mantenerla lo más simple posible (tal vez una clase que haga las peticiones y ya)? Gracias por compartir tus conocimientos 😁
Hola Marcelo. Normalmente las entidades y modelos hacen parte del dominio del problema. Qué tan robusta sea depende de qué tanta responsabilidad le quieras dar al cliente. Por ejemplo, hay personas que mandan toda la lógica de negocio al backend y dejan la app recibiendo y enviando DTOs. Saludos!
Cuando se derrolla una app movil en dónde hay que tener en cuenta que el usuario piede no estar conectado a un Internet, sería conveniente que la app contemple ese escenario y poder utilizar la app aun sin conexión a Internet. En todo caso yo casi siempre utilizo el peor escenario.
que es Lógica de negocio ?
Por aquí te cuento qué es: ruclips.net/video/fdnqf0qZUbw/видео.html
@@ManuelZapata Gracias, si justo ese me lo recomendó youtube. Muy buena info de tu canal, gracias Manuel !
No se por experiencia en un proyecto de un software contable la lógica de facturación que era calcular el total de una factura cuando se estaba creando el resultado era unos retardos por que cada ves que calculaba el subtotal de un producto hacía una petición servidor la experiencia de usuario era pobre entonces se recomendó que esa lógica de calcular el total estuviera en el cliente entonces se redujo mucho las peticiones de servidor y experiencia de usuario mejoro no sense ai esta logica es una parts De logica De negocio
Sí, eso haría parte de la lógica de negocio. Obviamente cada caso tiene sus particularidades, pero en las condiciones apropiadas lo ideal sería no duplicar la lógica de negocio en múltiples clientes.
La logica de formato de datos, ejemplo escritura de precios con decimal o miles, estructura de fechas, etc deberia estar en el cliente o servidor ?, Excelente video, muchas gracias.