commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Fabulich <>
Subject [beanutils] [dbutils] Interfaces as beans, for databases
Date Tue, 10 Feb 2009 22:28:39 GMT

Have you seen ActiveObjects?  It's an incubating ORM layer over at; it's got some neat stuff in it.

I'm especially drawn to the idea that a bean could be defined as an 
interface, rather than as a concrete implementation.  It saves me from 
having to actually define the implementation of getters and setters, while 
still preserving type-safety (and auto-completion in my IDE).

   interface Employee {
     public String getName();
     public void setName(String name);

It's easy to use java.lang.reflect.Proxy to automatically generate simple 
implementations for bean-like interfaces.  The InvocationHandler could 
just keep a DynaBean internally that maps properties to values; when a 
getter is called, we'd just call an appropriate getter on the DynaBean; 
when a setter is called, we'd just call an appropriate setter on the 

   Employee e = instantiateBeanInterface(Employee.class);

The result would be something like a type-safe DynaBean, which intrigues 

We could go even further.  Perhaps if the interface bean (IBean?) 
implemented other tagging interfaces, we could add in additional 

For example, BeanUtils could define an interface like this:

   interface DirtyManagedBean {
     public PropertyDescriptor[] dirtyProperties();
     public boolean isDirty(String propertyName);
     public void clean(String propertyName);
     public void cleanAll();

Then, I could make my Employee interface implement DirtyManaged, and have 
the automatically generated bean keep track of which properties were dirty 
(had been modified) and which were clean.

We could also have an interface like this:

   interface SupportsPropertyChange {
     public java.beans.PropertyChangeSupport propertyChangeSupport();

If my Employee implemented SupportsPropertyChange, I could retrieve its 
associated PropertyChangeSupport object and attach change listeners; we'd 
guarantee that the generated bean would fire change events via the support 


Specifically, I'm imagining IBeans would be helpful in the world of SQL 
databases, outside of any ORM layer.

1) You could automatically INSERT/UPDATE a DirtyManaged bean, adding only 
explicitly dirty columns to the SQL statement.

2) In general, an IBean could wrap around a PreparedStatement:

   PreparedStatement ps = prepareStatement();
   Employee e = proxyPreparedStatement(Employee.class, ps, columnList);

3) An IBean could wrap around a ResultSet; when you call .next() on the 
result set, the IBeans getters/setters could return the new values, 
eliminating the need to create N objects for N rows.

   Employee employee = proxyResultSet(Employee.class, resultSet);
   while ( {
     System.out.println("Name: " + employee.getName());
     System.out.println("Address: " + employee.getAddress());

3) If you're doing a join, you could define a new bean that wrapped around 
the joined query via multiple inheritance.

   interface EmployeeAddressQuery implements Employee, Address;

   Statement s = c.createStatement("SELECT * from employees, addresses");
   resultSet = s.executeQuery();
   Employee employee = proxyResultSet(Employee.class, resultSet);
   while ( {
     System.out.println("Name: " + employee.getName());
     System.out.println("Street Name: " + employee.getStreet());



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message