style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">

MVP

Hola a todos me interesa aprender mas sobre el patron MVP, pero pues he buscado y no encuentro algo por donde pueda empezar, alguien conoce un buen libro ó tutorial o algo por donde pueda empezar, para aplicarlo en java ó php, saludos

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de beto.bateria

Puedes estudiar el MVC

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

Imagen de bonfil1

Hola beto

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

Imagen de ezamudio

MVP?

Y de qué es la P?

Model–view–presenter

Imagen de ezamudio

presenter, view...

Presenter suena mucho a View...

Imagen de paranoid_android

Muy similar

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
https://developers.google.com/web-toolkit/images/testing_methodologies_object_diagram.png

Imagen de ezamudio

reinventando

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?

Imagen de paranoid_android

Asi es...

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.

Imagen de ezamudio

WTF?

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

Imagen de paranoid_android

Diferencia minima

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.

Siempre es lo meeesmo

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.

Imagen de ezamudio

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á.

Imagen de neko069

Qué no es MVP..

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

Imagen de echan

mvp

Imagen de echan

EJB es a java como MVC es a

EJB es a java como MVC es a smalltalk

http://c2.com/cgi/wiki?ModelViewControllerHistory

Imagen de bferro

Gui Architectures

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

Imagen de bferro

Y después seguir con:

Imagen de ezamudio

obsoleto!

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

Imagen de bferro

No es obsoleto

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

Imagen de luxspes

EJB es a java como MVC es a

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)

Imagen de luxspes

MVP no es un sofá!

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á!

Imagen de bferro

el peor fracaso?

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.

Imagen de bferro

El modelo de persistencia fue un error

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

Imagen de ezamudio

Opinión

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...

Imagen de neko069

Weblogic medio-mitigaba el

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.

Imagen de bferro

¿se han preguntado que otro modelo existía?

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.

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">