Presenter First: Data Binding and Adapters

Back in November I got an email from Jiho Han asking a question about Presenter First:

“In Presenter First, is databinding still feasible? I’m speaking about situations where you might have a 3rd party grid control where it is almost unusable without databinding.”

Happily, we have a new sample illustrating the Adapter extension to Presenter First. The application is a simple book inventory manager with a sophisticated editable table widget (JTable and TableModel data bindings) and MVP-triplet-to-triplet coordination between the editor components.

How Adapters help us encapsulate data-binding-oriented APIs

Data binding (the automated relaying of data between a data model and view) is a common and powerful tool that usually arrives out-of-the-box from our favorite GUI toolkits, like WPF, Java/Swing, etc. For many complex widgets, such data bindings might be the only way to control the user interface.

In Presenter First, we focus on Presenters—domain-level objects that exist between models and views. But a JTable is designed to bind to a TableModel . . . where’s the Presenter in this connection? How do we get in the middle of this model/view duet?

We don’t. JTable and TableModel work well together. Instead, let’s model at the domain level, where a LibraryPresenter sends updated Book data to a LibraryAdapter which manages (indirectly) a JTable and its TableModel and all the fussy API calls that go along with those classes. Despite its “model”-ish name, TableModel is really just our tool to control our JTable view.

Architecturally, the basic MVP triplet looks like this:

Inserting an Adapter between Presenter and View gives:

The Presenter acknowledges the Adapter as an advanced view, capable of dealing in higher-level, domain-specific data types. The Adapter does the heavy lifting of data transformation and widget manipulation.

In the sample code, there is one more piece to the puzzle: the LibraryAdapterModel, which is invoked by the Adapter to store translated data. This class references the actual TableModel implementation, in the guise of ILibraryTableModel. I usually represent Adapter/AdapterModel scenarios like this:

Interestingly, the LibraryAdapter brokers events and data between LibraryAdapterModel and LibraryView in the same way a Presenter brokers activity between a model and view.

Not all Adapter scenarios will necessitate an AdaperModel. The sample app manages several other pieces of interesting information, such as the currently selected library, which are not handled naturally by the TableModel metaphor.

(Jiho also asked why our C# examples don’t publicly utilize the common C# event system, to which I have responded to on Stack Overflow).

  • JK says:

    Hi, do you have sample on C#/ for data binding solution on Presenter First pattern?

    For Web development, which layer should the codes go for accessing HttpContext, session, querystring kind of stuffs, View or Presenter? I would think that these are all web related stuffs and it should go under View layer, but if this is the case, how does the presenter controlling the navigation between pages (it need to call response.redirect). And where should the codes go for storing stateful information into session/cache/viewstate in order to access them in different web pages.


  • David Crosby David Crosby says:

    JK: To my knowledge, Atomic has not applied Presenter First to web applications. The PF pattern lends itself nicely to story-driven development of features in stateful, event-driven desktop GUI environments, such as Windows Forms or Java Swing applications. For web applications, we prefer the stateless approach of model-view-controller frameworks like “Ruby on Rails”: and “ASP.NET MVC 2”: We’re using MVC 2 on several projects currently and are finding it to be a tremendous improvement over traditional ASP.NET Web Forms interfaces. If you’re interested, I recommend “Programming ASP.Net MVC”:

  • JK says:

    Thanks David, I had spent some time looking at MVC. My biggest concern is it does not work for server control (due to its viewstate and postback). It need to find way to rework on functionality such as paging, sorting etc in GridView control which are fairly easy to achieve in traditional Web forms. Besides, most of the existing customized user/server controls can’t be reused.

    It will be great if you could share on how do yours gone through these barriers during implementation of those projects using MVC 2.

  • Comments are closed.