When is a Tool not a Tool?

A couple weeks ago my colleague Brian LeGros published an article about Object Persistance and Architecture. It was a very good article in his series on design practices, but it made me think about some struggles I have had when working with persistance frameworks.

Before I begin I want to attempt to establish two seperate types of frameworks. The first type are like Rails, Fusebox, PureMVC, and Django. These frameworks establish guidelines for laying out your application, and are meant to be worked within. I believe this type of framework is usually used at the presentation layer.

The second type of framework is meant to work within your design, or help you achieve your design. This is important because the other frameworks you design within, these frameworks help you design. I hope I am getting my point across here, it seems a little confusing. These frameworks usually help you achive a specific goal, like persist your data, wire your objects, or validate your domain. Some examples include Coldspring, Hibernate, and OVal.

This brings me to the point I want to make with this post. The first type of framework dictactes how your project is designed, the second should not. The second should be used as a tool inside your design, and I think this is where many people, including myself, have shot themself in the foot when using these tools.

Lets take Hibernate as an example. Hibernate, if you don’t know, is a Persistance Framework aka ORM aka Data Mapper for describing and transfering your Relational Model to your Object model. If you are layering your application like a good developer you will use this tool in the integration layer.

Now this is my opinion, but I believe that the layer boundaries should not be crossed unless you have a really good reason. I personally do not think that using Hibernate, a tool, is a good reason to break my layering, and allow Hibernate to dictacte how I design my domain. This has really been a hard thing to do in practice, I find myself wanting to solve the problem as fast as I can, and I ignore any good layering or design practices. I allow my tools to dictate what my domain looks like. Although this will be good for churning out a quick product, I think in the long haul of an application, the maintence will be much easier if you have a well thought out business layer.

I didn’t mention iBATIS above but I like this persistence framework better than Hibernate because it allows me to very easily hide all the database details in the integration layer and not does even define any facilities that would possibly encrouch into my business layer.

At the heart of this post I realize I am reallying encouraging focus on each problem in the appropriate layer. Focus on solving the business rules in the business layer, solve the persistence problems in the integration layer. In addition I would suggest focusing most of your time and attention in the business layer, and leave the persistence layer for last. If you do this, in the long run you will have an easier time making changes to your application as business rules change. Because you won’t have to worry about how it affects how you save an object, because that is not a concern of your business layer, that is a concern of your integration layer.

This entry was posted in development, programming, theory and tagged , , , , . Bookmark the permalink.

4 Responses to When is a Tool not a Tool?

  1. Maxim Porges says:

    What have you found creeping out of Hibernate in to your domain?

    The only thing I can think of that might be construed as such as the ID (since Hibernate requires the notion of identity for every object), but arguably every object in a business system should have a surrogate identifier, and an ID certainly doesn’t negatively impacting the design of a domain to the point where you have to rethink your relationships or attribution.

    – max

  2. Daniel Roop says:


    It isn’t so much that I see Hibernate forcing any practice on you. My complaint comes more from people implementing it. After reading over my post, I realized I probably didn’t do my thought justice. I think what I was trying to say was something more like….

    Design your problem, not your app!

    Meaning, the majority of your time should be spent on designing your domain/business tier, and the integration and presentation should be after thoughts. So when you start by deciding you are going to use Hibernate, I think you may be focusing on the wrong problem at the begining of the project. I may be way off, but if you start with the tools you create the possibility to design around how you are persisting, instead of persiting your design.

  3. Daniel Roop says:


    I think we are both saying the same thing, use the right tool for the right job. I apologize if my definitions are a little off, but it seems that the entire programming community has issues defining these terms. If you do searches for ‘framework’ and ‘library’ you will have extremely varied results.

    Your interpretation suggests that a framework is involved in all areas of your application, whereas a library is focused around a single problem. I am okay with that definition. I have also seen a definition that suggests a framework is anything that dictates how your code should be written, and a library is something you call for a specific function. With that definition I think hibernate would be a framework not a library.

    Regardless, we agree (I think) always use the right tool for the job.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>