IN Vs EXISTS

Un link muy interesante para entender las diferencias entre el IN y el EXISTS en SQL

http://oraclexperto.blogspot.com.ar/2005/09/in-vs-exists.html

MVP VS MVP

Aquí encontramos varios links que nos permiten entender las diferencias y similitudes de estos dos patrones de diseño

http://blogs.infragistics.com/blogs/todd_snyder/archive/2007/10/17/mvc-or-mvp-pattern-whats-the-difference.aspx

http://martinfowler.com/eaaDev/uiArchs.html

http://code.google.com/p/gwt-mvc/wiki/MVCvsMVP

For GWT development, the View/Model interaction causes some difficulties. First, having the Model communicate changes to the View is complicated (though you may do with Comet, but that’s not usually practical) because of the server/client separation. 

Reciprocally, having the View send queries to the Model makes testing harder (as we’ll see in Chapter 13) because it requires using GWTTestCase, which is slower.

1. The Model has the same role as in MVC, but it communicates only with the Presenter, which can send it both model update commands and queries.

2. The View has a similar role as in MVC, but it doesn’t communicate with the Model any more. Whenever the user does an action, the View informs the Presenter about the event, which may in turn ask the View to update itself.

3. The Presenter is key in this pattern, for it is a bridge between the Model and the View. In response to the user events, it can communicate with the Model, and depending on its answers, send update commands to the View.

In this pattern, the (humble) View is quite simple and practically has no logic at all. Mostly, it will have code to create and displays widgets to get or set their values and to dispatch user events to the Presenter. If the user enters a value in a widget, the View won’t do any validation; rather, it will notify the Presenter about the data change, and the Presenter will be responsible for the validation.

In terms of testing, we hope to be available to skip testing the View (because of its simplicity) and work with a mocked instance of it, which we’ll access only through its Display interface.

[Texto extraído de Addison Wesley 2011 Essential GWT Building for the Web with Google Web Toolkit 2]

La Vista

The view is the user interface. It may contain text fields, images, forms, buttons, links, and many other widgets. The view does not and should not know what it is displaying. This means that it does not know the kind of model it is using because the data sent to the view is in primitive formats such as string, date, and image, via a display interface.

El Modelo:

The model contains the data to be displayed. It is not aware of the component that is going to display it or how it is stored in the Datastore. It is a data container.
The model data can come from a Datastore via a Data Transfer Object (DTO) fetched

ver a server call or from an Event Bus.

In GWT MVP, models are shared between the frontend and the backend. Therefore, models are often Data Transfer Objects (DTOs) that are serialized before transmission.


El Presenter:

The Presenter contains the business logic of the triad. That's the boss. Its role is to send updated data to the view and read back values from it if it changes. It also listens to events sent by other application components. It can also fire its own events on the event bus. The presenter gets its data from the Model. Presenters and views are coupled via a View Interface

[Texto extraído de Google.App.Engine.Java.and.GWT.Application.Development.Nov.2010]