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?

Leave a Reply

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