MVP

Puedes estudiar el MVC primero, hay mas informacion, y despues te va a ser mas facil entender el MVP.

El punto es que ya manejo MVC y ahora quiero aprender MVP, pero no he encontrado buenos recursos para aprender, saludos

Y de qué es la P?

No lo conocia como tal MVP

Presenter suena mucho a View...

Hola. Yo tampoco lo había escuchado, al parecer es muy similar aunque cambian algunas responsabilidades. En java se usa para tecnologías como SWING, SWT, GWT.
Segun la pagina https://developers.google.com/web-toolkit/articles/testing_methodologies_using_gwt

The pattern is very similar to the more widely known MVC pattern, however rather than have the presentation logic shared by the Controller and the View, in MVP, all presentation logic is pushed to the presenter.

MVC

MVP

Responsabilidades

Ok. Seguimos reinventando el hilo negro entonces.

El modelo MVC nació para aplicaciones de escritorio en los 80's, es más viejo que la web. Luego se aplicó para aplicaciones web, pero y luego? Parece que no se adecuaba muy bien y por eso hicieron el MVP que no es más que una ligera variante, pero luego se la llevaron de regreso al escritorio?

mmm desapareció mi post anterior lo marco como spam...

Es la misma idea y varia muy poco, según lo que entiendo es mas como lo implementan las tecnologías estilo JSF vs SWING por ejemplo. Pero en el fondo no tienes opción a utilizarlo digamos si usas JSF no podrías usar MVP y viceversa si usas swing no deberías usar MVC.

Si uso swing no debería usar MVC? Pero si esa madre fue diseñado con MVC en mente!

Me exprese mal "deberías" - "podrías" Swing si fue diseñado con MVC en mente. Creo que por la manera que estan implementados los controles. El proceso está escuchando las peticiones del usuario y que componente debe responder a esas peticiones.
En MVC en JSF comienza la logica en el Bean correspondiente a la Vista mientras que en Swing el Listener que es el Controlador.
No tendrías opción a cambiar ese orden.

En realidad es tan similar que la diferencia sería donde está la lógica.
Según la página de GWT en MVC está en la capa de Vista y Controler mientras que en MVP la lógica queda aislada y unida en la capa de Presentación.

Aunque en la práctica puede ser de otra manera y tambien puedes repartir la lógica en otras partes.

MVC no es framework, es un patron que te dice que es importante separar las operaciones con los repositorios de datos, los componentes de negocio y finalmente la presentacion que le das.

Supón que un banco te pide desarrollar el servicio de consulta de saldo y un requerimiento es que lo puedas consultar desde tu telefono y desde el cajero y desde telefono. No necesariamente tienes que hacer un sistema completo por cada uno de las interfaces de usuario porque finalmente se tiene que hacer lo mismo.

Para mi ejemplo, creo que el MVC mas bien debe llamarse algo asi MCC (Modelo Cliente-Controlador, que no sé si exista) y la interfaz de ususario es el cliente dado que en el telefono no tienes una vista o algo grafico.

Dicho lo anterior podemos decir que tu aplicacion bancaria (uses lo que uses en cuanto al cliente) utiliza el mismo componente para consultar la informacion, los mismos componentes de negocio y donde está la diferencia es en el cliente que consuma tus operaciones. Pero sigue siendo un patron no una herramienta/framework.

No veo un solo comentario donde alguien dijera que MVP o MVC fuera un framework. De hecho la primera mención que hay de "framework" en todo el post es el tuyo, diciendo que no es un framework.

Siguiendo esa línea, yo digo: MVP no es un sofá.

MVP No es el jugador más valioso ... O sí.

jejeje

EJB es a java como MVC es a smalltalk

Quizá les interese leer este artículo Gui Architectures de Martin Fowler

Para después seguir con Retirement note for Model View Presenter Pattern

Wow o sea que ya es considerado obsoleto, ahora hay dos patrones en su lugar... interesante.

No es obsoleto, es un punto de vista de Martin Fowler a la hora de presentar la solución y el problema.

EJB es a java como MVC es a smalltalk

Nop, EJB es el peor y mas grande fracaso de Java.

MVC fue formulado en Smalltalk... Y su trayectoria ahi, y despues en incontables lenguajes no es ni remotamente el horroroso trayecto de los EJB, que si no fuera por los EJB3 (que basicamente los convirtieron casi en POJOs) hubiera terminado en su muerte.

Ademas, los EJB son la implementacion concreta (y hasta antes de EJB3 bastante mala) de ciertos patrones. MVC no es una implementacion, es un patron (para el que existen muchas implementaciones, como Spring-MVC, ASP.NET MVC, etc, etc)

Siguiendo esa línea, yo digo: MVP no es un sofá.

Jajajajaja.... estoy totalmente de acuerdo

Y aprovecho para comentar que los EJB no son un patron... ni tampoco son un sofá!

No he leído en ningún sitio neutral serio (salvo en los de la competencia) que EJB haya sido el peor y más grande fracaso de Java.

Lo que sí es cierto que el manejo de objetos persistentes, tanto con CMP y BMP Entity Beans (que eran parte del modelo de ocmponentes de negocio de EJB) fue un fracaso que llevó a la creación de JPA como parte de Java Enterprise Edition. Los EJB de sesión se han seguido usando y su uso ha aumentado después de EJB 3.0

Creo que fue una opinión personal de luxspes. La cual comparto. EJB pre-3.0 APESTA. Para publicar un simple EJB era una pesadilla que si el locator que si el remote y el local o no sé qué tanta idiotez, más todo el XML para poder echarlo a andar...

Weblogic medio-mitigaba el dolor de crear los EJB con el IDE que antes manejaba (Workshop o algo así) había la opción de crear un proyecto EJB y el IDE te ayudaba en la configuración del XML ... fuera de ése asistente, nunca encontré algo parecido.. tampoco es que me apasionaran los EJB 2.x Y complementando la analogía de luxspes, si pudiera decir qué es EJB (2.x) sería como un potro de la santa inquisición.

EJB antes de EJB 3.0 fue un modelo de componentes "pesado", con mucho código de la aplicación dependiente del modelo, pero en el momento en que surge no existía otro modelo "conveniente" para que el código de plomería que un componente de negocio requiere, se pudiera "insertar" de manera declarativa en el código de run-time. No existían las anotaciones para la inserción de metadatos, por lo que la única opción para declarar las necesidades del componente era mediante archivos de configuración externos y la decisión "lógica" era usar XML para esos propósitos.
Nunca fue tanta pesadilla armar todo lo que un objeto de negocio requería pues los IDES automatizaron todo el proceso de crear las interfaces de negocio, las interfaces home, etc. No se hablaba aun de inyección de dependencias ni de otras cosas que contribuyeron sin duda a que la versión de EJB 3.0 arreglara parte del desmadre.
El problema principal de EJB no fue tanto con los ejb de sesión ni con los de mensajería. Su bronca siempre estuvo en los EJB de entidad para manejar la persistencia debido fundamentalmente a que los vendors de app servers lo implementaban a la manera de cada cual y la portabilidad de las aplicaciones se venía abajo cuando decidías abandonar a BEA como vendor y te pasabas a IBM.
Los que diseñaron esos modelos aprendieron rápido la lección y abandonaron eso para, entre otras cosas, crear JPA.