Frank W. Zammetti wrote:
I think it usually comes down to three reasons...
I'd add a fourth, although really it's just a result of the reasons you
mention. But I think it's important enough to warrant attention :)
(4) Dependency Injection/Configurability.
Classes that implement interfaces can be instantiated at runtime
allowing for config-file-level application modification. This can
translate into HUGE wins over the life of an application.
As a recent thread on DTOs pointed out having multiple implementations
of CRUD actions can be REALLY handy: I have an existing application that
uses Torque for persistence. I refactored out a lot of the typical CRUD
stuff into an interface, implemented a default Torque CRUD base class,
whung up a configuration file, and can now perform the most general CRUD
actions on my DB by giving a tablename String.
When I migrate this to Hibernate "all" I'll need to do is implement a
generic Hibernate CRUD base class (and perhaps some specializers for
particular tables/OMs), change the class names in my config file, and my
application will work as before without having to change any of my Actions.
Business logic will also be unaffected by the persistence mechanism change.
Jython utilities and GUI apps will also run unmodified: I use the new
Hibernate implementation, use the same config file, and everything is ducky.
I get giddy just thinking about it.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
