Avoid Hibernate Anemia and Reduce Code Bloat

One of my beefs with Hibernate as an ORM is that it encourages anemic domain models that have no operations and are simply data structures. This coupled with java's verbosity tend to make code unmaintainable (when used by third party systems) as well as cause developers to focus in THINGS instead of ACTIONS. For example take the following class that represents a way to illustrate part of a flight booking at an airline:

public class Flight {
    public Date start;
    public Date finish;
    public long getDuration() {
        return finish.getTime() - start.getTime();
    }
}

This is the core "business" requirement for a use case in this model in terse java. Form an OO perspective, start and finish are attributes, and getDuration is an operation (that we happen to believe is mathematically derived from the first two fields. Of course, due to training and years of "best practices" brainwashing, most folks will immediately and mindlessly follow the java bean convention making all the member variables private and "just generate" the getters and setters. That makes the same functional unit above look like the following:

public class Flight {
    private Date start;

    public Date getStart() {
        return start;
    }

    public void setStart(Date start) {
        this.start = start;
    }

    private Date finish;

    public Date getFinish() {
        return finish;
    }

    public void setFinish(Date finish) {
        this.finish = finish;
    }
    public long getDuration() {
        return finish.getTime() - start.getTime();
    }
}

Wait, we're not done yet, if we want duration to be persisted, we'll move the logic to another class and add getters and setters:

public class Flight {
    public Date start;

    public Date getStart() {
        return start;
    }

    public void setStart(Date start) {
        this.start = start;
    }

    public Date getFinish() {
        return finish;
    }

    public void setFinish(Date finish) {
        this.finish = finish;
    }

    public Date finish;

    private long duration;

    public long getDuration() {
        return this.duration;
    }

    public void setDuration(long input) {
        this.duration = input;
    }
}

public class FlightHelper {
    public static long getDuration(long finish, long start) {
        return finish - start;
    }

}

This "Helper" or "Business Delegate" pattern is yet another area where things go wonky very quickly. Usually, to keep things "pure" folks will put all logic in the helper (or delegate, I'm not sure if there's a difference) and the model will have no logic. This really makes troubleshooting where the logic is contained very difficult. In addition, having a computed and stored field is fraught with potential for errors. Java folks will typically make the case that this class is really a Data Transfer Object (DTO)... OK, fine, but that's like saying an elephant is actually an herbivore...

But wait...it gets worse...

What I often see happen among java circles is that this is a death spiral of bloat in the interest of "best practices". A typical next step is that, folks invariably realize that serializing hibernate objects to remote servers or tiers that don't have access to hibernate becomes a huge challenge due to hibernate's technique of using AOP to actually replace the real object with a dynamic proxy. To get around this, developers invariably create another layer of DTOs or "Value Objects" as well a mapping layer to map between these two domains.

In conversation with most java developers about "why are we doing it this way?" I get blank stares and the best answer I've heard is "because that's the way we do it" or often a link to a web site explaining how to do it and why which ultimately is really just a clever way of saying "I don't know". Crafty individuals will then start talking about java patterns and all sorts of other artificial explanations that never explain "why", but simply re-endorse "how".

A way to mitigate this problem is to start decomposing application components functionally and realize that data persistence is in fact a first order operation in most systems. This means that persisting data should be atomic and a single step operations (hint: If you need a transaction manager the call is NOT atomic). Additionally, putting these behind web services means that the idea of persisting data becomes an internal responsibility and not something a caller needs to know or care about

Put another way, hide our persistance layer behind an API and don't create superfluous classes that need to be shared with third parties. So, in the example above, you could do something like:

public class FlightService {
    public Date getStart(long id) {
      //...implementation here...
    };
    //create a flight and return the identifier
    public long createFlight(Date start, Date finish) {
      //...implementation
    };
    ///Returns duration
    public long setStartAndFinish(long id, Date start, Date finish) {
      //..implementation here...
    };
    public Date getFinish(long id) {
      //...implementation here...
    };
    public long getDuration(long id) {
      ///...implementation here ...
    }
}

This preserves the idiomatic java, plus enables us to completely hide the implementation details from the caller. Yes, it introduces a transaction and granularity problem that we immediately need to solve... and should force us (unless we really want to do it the hard way) to start thinking about he API contract for atomic operations. I think this is the important distinction and shouldn't be forgotten. Worry about what your design is supposed to DO first as at the end of the day, the OPERATION is more important the the MODEL.