A Software Framework I Actually Like

Generally speaking, I hate frameworks. Most frameworks I’ve met fall into one or more of these camps:

  • Frameworks so lightweight that they’re not worth the hassle of using them.  These frameworks can be useful when you need some functionality that you don’t want to learn in detail how to do.  This is almost never the case for me, because I like fully understanding any technologies I rely upon.  That’s why at Aptima I wrote my own AJAX JavaScript library.  It was something like 50 lines of code, worked flawlessly, and worked exactly as I wanted it to.
  • Frameworks so heavy the work to utilize them approaches the work of rolling your own.  This often happens with frameworks that start out simple and are expanded to encompass too much functionality outside of the original scope.
  • Frameworks that are staunchly inflexible in how they are used and how they work.  Using a software tool to make your life easier should not like  implementing an ERP system.  This often happens when when the framework was designed for a specific purpose then released as a separate product.  See The Cathedral And The Bazaar.
  • Frameworks that are completely opaque or have an unreasonable learning curve.  Most meaningful operations in software have some sort of side effect you need to be aware of.  Insufficient documentation and software that does not follow the mantra of the Principle Of Least Astonishment can make diagnosing problems a nightmare.

I’m currently working on my knowledge and skills with Spring and Hibernate.  They continue to fail to suck.  I was very surprised how easy they were to implement, how much they’re for me, and how flexible they are.  Spring is a framework that specializes in (among other things) inversion of control to promote decoupling and testability, and Hibernate is an object relationship mapper that eases the burden of persisting entities in a database.  There are many good tutorials on the Intertubes, but I’ve been working my way through the book Spring Recipes, which covers both technologies very well.

I’m working on a project now called Lists Of Links (LOL).  It’s going to be a web-based application to store and view bookmarks in a hierarchical tree.  It’s going to have some fancy features, like storing multiple lists of links, password protected lists, and the ability to link from one list to another.  I’m writing this because I haven’t been able to find an application like this (I don’t want a bookmarking service because I don’t like storing my data on other peoples’ machines), and specifically to gain more experience in Spring, Framework, AJAX, JQuery, and REST.  When I’m done (or possibly before) I will release it as open source.

As I’ve mentioned, Spring has several very different components, but they all build upon IoC (inversion of control), a technique for decoupling software components from each other by passing the dependencies in (as parameters to a setter or the constructor) instead of instantiating them in the class.  For instance, let’s say many parts of  your application requires an instance of the class CurrencyConverter.  Instead of instantiating one in each component, you define one in the Spring configuration, and fetch it from the Spring context where needed.  Not only does that mean there’s only one instance of it (yes you can create your own singleton, but that’s actually more work), but if you access it as an interface in your application, you can change the implementation in the configuration file without recompiling your code.

This is a powerful tool for letting deployers control the installation.  Another great example, straight from the Spring Recipes book, is having multiple implementations of your DAO (Data Access Objects).  If you have an entity Foo that needs to be persisted to a database, you can create an interface FooDao that defines the storage and retrieval methods, and multiple implementations, like HibernateFooDataImpl and JpaFooDataImpl.   In your program, you create variables of type FooDao, and get whichever implementation is defined in the Spring configuration.   This allows a lot of deploy-time flexibility.  The same technique can be used for altering the logging, profiling, internationalization, or any other service you can think of.  It also means less code duplication.

Hibernate is a separate product altogether, but they are made to work well together.  An ORM eases the burden and complication of persisting business objects in a database, and makes it trivial to move from one DBMS to another.  It does this by generating DBMS-specific SQL and normalizing the DBMS-specific error codes.  Queries are written in HQL, which is a kind of simplified SQL.  At runtime, that the HQL gets turned into SQL based on the current configuration.  The  ORM standard JPA became a part of Java EE (nee J2EE)  and EJB 3.0.  Hibernate  can be used as a JPA Engine, or used directly.  In both cases, it integrates very well with Spring.

Here’s why I am becoming a fan of Spring and Hibernate:

  • Both of these frameworks are incredibly flexible.  They can be configured programmatically, using annotations, using XML files, by naming convention (like @Autowire), or a combination of all of these.  Your choice, because they’re all fully implemented and equally as powerful and flexible.  Of course there are trade-offs for each (for instance, XML file configuration allows deploy-time choices, but annotations ensures the database design and entity design stay in-sync).
  • Both of these frameworks can be used to a greater or lesser extent, letting you choose how much you want them to do for you.  For instance, you can use Spring to just give you access to a shared DataSource you use with your own JDBC, use its JDBC templates to eliminate about half the code you have to write, or use its JDBC helper classes where you don’t have to do much more than specify SQL fragments.  You can choose to to programatically get instances, provide getters for Spring to pass them to you, or have Spring “figure it out” with @Autowire.
  • Both of these frameworks come as modular .jar files, so you can include as much or as little of them as you want.  Spring also has the “One Jar File To Rule Them All” if you want everything in one .jar file.
  • Both have great documentation and books available, many examples on the Intertubes, and a very active community.  I was having a problem with Spring last night, and went on the #spring IRC channel.  Not only did someone explain how to solve my problem, but someone else followed up with an improvement in it within minutes.

I look forward to learning more about Spring and Hibernate, but so far, I like what I see.  In LOL, I’m using Spring and Hibernate to handle all the SQL.  It means most of the methods in my DAO are about four lines of code.  I don’t have to worry about transactions, enforcing validation rules, and even creating the UIDs automatically.  If you’re interested in that project, I’m going to keep the LOL page updated.  And yes, I picked that acronym on purpose.

I welcome your comments.

Share

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.