Hello "Hiveminders", While working on a generic Transaction Service framework, with particular focus on Hibernate, I thought about the annoying problem of checked exceptions thrown by almost all methods of all Hibernate classes. Having to try/catch these exceptions again and again makes it boring to write DAO that will eventually be hard to read just because of that.
My first idea about the problem was to do something like Spring does, ie define an Hibernate "ersatz" (HibernateTemplate, a substitute wrapping most commonly used methods), but I did not really adhere to such an idea since: - it restricts the full view of Hibernate to developers (I know spring does not prevent you from accessing directly all Hibernate stuff, but who does it actually?) - it means that developers do not _really_ develop with Hibernate but with Spring-integrated Hibernate through Spring classes Then, I wondered if it would not be possible to do, for any DAO, something like: - create a DAO interface with all necessary DAO methods with NO HibernateException - implement a DAO class that DOES NOT implement the DAO interface but has the exact same list of public methods (exact means same name, same args types, same return types), but each with a throws HibernateException clause. In this case, the methods do not have to try/catch HibernateException and their code is reduced to the bare minimum - have some kind of "adapter" from the DAO interface to the DAO class, that would catch all HibernateExceptions and replace them with "something else" (unchecked exception) After a few tests I could write a ServiceImplementationFactory that just does that: - instantiate a service implementation - create an adapter (proxy) that implements a different interface and delegates all method calls based on method name and args types, catches all exceptions and uses an "ExceptionMapper" object to translate them to some other exception that is thrown instead As of today I have something that seems to work correctly (I did not fully test it yet, yes I know, "my code sucks" as said somewhere on TSS ;-)). It can be configured the same as Hivemind BuilderFactory (DI, autowire...) and has extra parameters to configure the exception mapping (from/to pairs of classes). After that I realized that this could be used more generally (without exception mapping) to be able to adapt classes that come from a 3rd-party library which we do not have the source, and which do not implement any interface. The trick would consist then in creating an interface that has all public methods of that class and use that special factory, et voila! I will put the current code soon on JIRA (on the bug regarding support for classes without interfaces). Please do not hesitate to comment on this. Some additional point then puzzled me (I come back to my DAO problem) from the design viewpoint. Creating a DAO interface and a DAO class that do not implement that interface kinda sucks right? In particular, even without considering the design, but just the time to develop/test/debug such a DAO (I do not even dare talk about evolutions...) it is easy to forget to code a method in the DAO class that is in the DAO interface. For now, I did not find any workaround to avoid this. Any ideas? The best I could do (better than nothing) was to log warnings at service construction time when the implementation class does not implement ALL methods of the interface. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
