The Java Beans Binding API (JSR 295) was designed mainly to solve the problem of binding user interface components to business objects in a Swing application, thus reducing tedious hand-coding of property change listeners. In an interview with Artima, Beans Binding JSR spec lead Shannon Hickey noted that there is nothing in the API itself that limits its use to that primary use-case.

Indeed, in a recent blog post, BeansBinding: not only for the GUI?, Fabrizio Giudici points out how the Beans Binding API can be used to automatically bind business objects to the persistence layer in a rich-client Swing application. In the process, Giudici also describes an important design pattern that explains the relationship between UI, business objects, and the persistence layer in a Swing application.

"Beans binding" is, in general, any Java technology that allows to automatically bind some properties in a plain JavaBean class to a GUI form. There have been libraries around for beans binding since a few years, but the thing is getting more and more interest because of JSR-295, an official specificaion from Sun together with its reference implementation...

A very common pattern that people use, probably influenced by some J2EE blueprints [consists of]:

• The GUI calls the Business components
• the Business components call the Persistence components

[As a result,

• GUI components depend on Business components
• Business components depend on Persistence components

This approach is clearly influenced by J2EE blueprints... There are two major drawbacks here: Beans Binding is basically used as an alternate approach to implement MVC for the GUI and the Business objects without requiring you to write specific listeners; instead, Beans Binding takes advantage of the standard java.beans.PropertyChangeListener implemented in the Java runtime, posing as an additional requirement that all the involved objects are compliant with the JavaBeans specification (remember that a "real" JavaBean is not the same as a POJO, as it must have proper event notification upon every property change)...

Giudici proposes that a similar approach be used to bind the business objects to the persistence layer. This would allow, for example, to persist changes to objects state without having to write explicit listeners by hand:

If the relationship between Business and Persistence can be expressed as a kind-of-MVC, why don't we use Beans Binding to take care of the relationship between Business and Persistence too?

Form, Domain Object and Persistence are pretty much decoupled each from the other—it's up to two special services, the UI Binder and the Persistence Binder, to use JSR 295 for keeping them synchronized. Any change in any object will properly reflect into the others: this happens both if the user types something in the form (and the update is propagated to the Business and Persistence objects) and if something changes in Persistence (and the update is propagated to the Business and the Form); of course changes could also originate in the Business Object (e.g. a timer triggers) and the other two are updated.

What techniques do you use to tie the business object layer to the persistence or remote data access layer in your rich-client applications? Do you agree with Giudici that the Beans Binding API is a good choice for binding the persistence and business objects layers as well?