Yes and Yes! There is absolutely a lot of potential there -- it's also one of the reasons I'd really like to see RowHandler become a first class part of the dbutils library -- ProxyGeneratingRowHandlers could do all sorts of interesting things.
On Tue, Feb 10, 2009 at 5:28 PM, Dan Fabulich <d...@fabulich.com> wrote: > > Have you seen ActiveObjects? It's an incubating ORM layer over at > dev.java.net; it's got some neat stuff in it. > > https://activeobjects.dev.java.net/basic-concepts.html > > 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 DynaBean. > > Employee e = instantiateBeanInterface(Employee.class); > > The result would be something like a type-safe DynaBean, which intrigues > me. > > We could go even further. Perhaps if the interface bean (IBean?) > implemented other tagging interfaces, we could add in additional > functionality. > > 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 > object. > > FOR DATABASES > > 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); > employee.setFirstName("Dan"); > employee.setLastName("Fabulich"); > ps.addBatch(); > employee.setFirstName("Somebody"); > employee.setLastName("Else"); > ps.addBatch(); > ps.executeBatch(); > > 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 (resultSet.next()) { > 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 (resultSet.next()) { > System.out.println("Name: " + employee.getName()); > System.out.println("Street Name: " + employee.getStreet()); > } > > Thoughts? > > -Dan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
