Fictitiously Asked Questions

Why another JDBC framework?

Good question. There's quite a few out there. Unfortunately, most of them imposes some sort of restriction on your classes, either in terms of having to implement an interface or extend an abstract class, or by forcing the JavaBeans model on the class design.

What is wrong with JavaBeans?

There's nothing wrong with JavaBeans as a component model, but it's a bad design decision to make all classes JavaBeans, especially if the only reason is reliance on a O/R framework. The JavaBeans model is inherently anti-OO, and has unfortunately become very popular with said frameworks. JavaBeans properties are inherently atomic and a class must have a default constructor. Those two things makes an instantiated object open for invalid state, something that leaves your software vulnerable to bugs. Hibernate gets around this requirement by allowing private properties. This however, can create problem with SecurityManagers, particularly on some application servers.

What are the dependencies?

Java 1.4 is the only dependency. Obviously if you want to use either Velocity or FreeMarker for dynamic SQL statements, you need to include those classes.

Should I switch from Hibernate, iBatis, or [whatever] to O/R Broker?

Not necessarily. If you can live with the limitations on object design that some products impose, and you're happy with the complexity of other products, then there's really no reason to switch.

Does O/R Broker support stored procedures.

Yes, stored procedures are supported, and can map to a result object, either through a returned result set, or by using INOUT/OUT parameters.

I just want to use a plain JDBC Driver, not a DataSource. Why is that not supported?

Only DataSources are supported, but you can use one of the many DataSource implementations that simply wrap a JDBC Driver. The Jakarta commons DBCP comes to mind, specifically the BasicDataSource class.