The Part Time Developer 5: Spring

So now that I’m relatively back in the land of the healthy (except for some remaining congestion and constant runny nose) I figured I needed to come clean with what I’ve been working on. Before the big week of sickness I had started to reacquaint myself with the Spring Framework, which is now up to version 2.5 (I’m not sure but I think when I was using it it was like version 1.2 or something). I was working my way through a pretty nice little tutorial on Spring MVC. I continued it over lunches at work this week, and expanded on it this weekend.

Let’s get a little explanation of what this stuff is. Spring’s basic claim to fame (though not only) is dependency injection (or Inversion of Control). This allows you to “inject” things into your programming objects that they “depend” on. This is easiest to understand with an example. Most of this stuff involves programming to interfaces. As I’ve mentioned previously, interfaces are like placeholders in code that state the type of object it can be (I’m finding this leads to too many examples.) For example, an Animal interface could have an eat() method, and then I could have a Dog class that implements the eat() method. So then wherever an Animal is needed, I could use the Dog class since it implements the requirements of the Animal interface (namely the eat() method). (Sometime I’ll have to do a Programming terms for non-programmers series.)

So let’s say I’ve finally put some functionality in place in Pit where police show up and start fighting with fighters involved in a Black Pit fight. Let’s say I’m smart and I have a Fighter interface that spells out such things that Pit combatants can do, like attack(). Let’s say that my PitFighter class that is used most everywhere is the type of object that will represent my police. So both the fighters and the police are the same type of object.

Now let’s say down the line I decide I want to spice things up a bit and change the police normal fighter types to be ravenous bloodthirsty animals. I create a PitAnimalFighter class which implements the Fighter interface, maybe this prints out “GRRR!” in it’s attack() method.

Now that I have the new class, the hard way would be for me to go and change over to using that class everywhere in my code that I want to use the animal to represent the policing entity. The easiest way would be, if I had this all set up ahead of time, would be if I had a configuration file (in XML) that mapped the type of class that I wanted to use for the policing entity interface. So all I’d have to do would be to change it over to my new PitAnimalFighter. Spring would do the rest by injecting a class of that type in where it was needed.  It would also be simple to change back if I needed to.

I don’t know if this rambling would make any sense to anybody, but I understand it, which is the point of this. One thing Spring can suffer from is XML hell. You have all this wiring that you do in XML files for what injecting these class types and other dependencies that it’s not always readily apparent. It can get a little confusing. The hardest part for me is all the secret little hidden things (that I’m sure are in the documentation) that I would need to use during the tutorial. I don’t know if I’d be able to make a Spring MVC application from scratch without heavily looking back at examples.

Oh yeah, Spring MVC.  MVC stands for model/view/controller architecture.  It’s just getting big in the .NET world but has been in the Java space for a while.  It aims to separate the dependencies within your code on each other.  So for example you create a web application.  If you have the code that deals with displaying it on a web page tied too closely to how you get your data, it would be difficult for you to create a desktop version of the app.  By using MVC correctly, it should be easy to change your front end or back end, since they aren’t tied together.  Spring does all the tying together with its injection mechanism.

Today I added an extra step to the tutorial I ran through by adding Hibernate as my persistence framework in place of the Spring JDBC persistence.  This nicely illustrates how easy it is to switch this sort of mechanism when you code to interfaces and use dependency injection.  I plan to document this in my next installment.

I’m guessing once I do part 6 of this series I’m planning to work on my own application using Spring and Hibernate together.  While I’d like to move on to the next technology in my list, I need to delve more into these two main technologies since my having a good understanding of these is essential.



%d bloggers like this: