somewhat daily mutterings

/Programming/Java Spring 2004 RMSS Reflections

Let's get straight to the point: this RMSS was basically about three main topics: Spring, Hibernate, and AOP. Aspect-oriented programming, combined with Spring (or other lightweight containers) and Hibernate was essentially declared to be the death of EJB (or at least the death of the "need" for EJB). To be sure, the larger shops will continue to buy into the EJB story sold by the large vendors, but the smaller and more "agile" teams will likely forego the EJB approach.

Speaking of smaller and more agile teams, the Spring/Hibernate focus was fine by me, since it strongly validated my recommendation to my (relatively) new team at that we use Spring in the development of the new version of our product. We incorporated Spring into the "new" section of our codebase about eight weeks ago, and have never looked back. We've also basically assumed we'll use Hibernate at some point, as well so we're pretty well aligned with the brave new world. It was a kick for us to be able to raise our hands in response to the presenters' queries of, "who here is using Spring?" In contrast, when I worked for BEA, I often didn't get to use some cool stuff because it may have called into question the usefulness of BEA's own products. The order was always "BEA on BEA." Now I have no such restrictions, and I'm like a kid in a candy store (but I'm still selective with my sweets).

Unfortunately for the RMSS experience, my cool work toolset had a surprising downside: there just wasn't a lot of new material for me to absorb this time around. I mean, it was all fresh material, but I've been reading (and doing) so much with the new toys that it was hard to find sessions that really intrigued me. Since we use Spring I have no interest in AspectJ (plus, I'm still trying to get over my dislike of source annotations and/or language extensions). I really wanted to get into a Groovy session, but the first one conflicted with Dave Thomas' Pragmatic Mock Objects session, and the second was jam-packed by the time I got to the room. I ended up going to several of Bruce Tate's sessions, although he's not one of my preferred presenters (nothing personal - he seems like a very fine fellow), because he was doing most of the Spring and Hibernate talk, several of Glenn Vanderburg's sessions (always a favorite of mine) because he's just plain a great presenter, and a couple of Daniel Steinberg's sessions (Jini - thumbs down, Max OS X Java Hacks - thumbs up).

Posted: Wed May 26 04:37:57 -0700 2004

/Programming/Java To DTO or not to DTO?

This is a work in progress!

There seems to be a lot of debate lately on whether DTOs (Data Transfer Objects) are a good idea. Seems as though the Hibernaters are now saying "without EJB to muck things up, why do I need DTOs - they were just a hack pattern to get around the problems with EJB". Well, as much as I approve of throwing EJB out of many solutions, I think jettisoning DTOs as well is throwing out the baby with the bathwater.

Here's why: I happen to still think that we should tier systems (logically, at least), and as such, have a services layer that defines the boundary between the front and back-ends of our systems. I think most people still agree with that notion. Why do I like service layers? Generally, because they decouple the business rules end of the system from the presentation end, and through decoupling, promote the separation of concerns. Of course, if you're no longer tiering your systems you can ignore my arguments.

So, what are the concerns of which I speak? The way I see it:

The concerns of the front-end are:

  • presenting data to the user
  • gathering data from the user
  • performing minimal data checks
  • navigation through the system
  • security
The concerns of the back-end are:
  • getting/storing data
  • performing maximal data checks
  • carrying out business rules
  • defining and executing transactions
  • security

The creation of a service layer promotes separation of concerns by creating a "facade" (the service interface) between the front-end and the back-end. It's clear (to me, anyway) that business logic belongs behind the facade, and anything that sneaks though the facade from the service to the front-end represents a possible "leak" that can be costly in the future. Prevent the leak by communicating with the front-end via DTOs. Because DTOs are stupid data holders, they convey very little about the implementation of the service. Having clients communicate with services only via DTOs promotes decoupling by keeping the front-end of the system ignorant of the workings of the back-end.

The other alternatives, as I understand it, are to allow the client to access the domain model, either 1) directly, or 2) via a service interface.

The first approach just feels wrong to me, having argued for a service-based architecture in the first place. In my experience, when domain objects are exposed directly to client code, the two have a tendency to become intermixed, which anyone will admit to be a bad thing. A service-based approach at least draws a line in the sand to make it obvious when rules are being broken.

The second approach still has problems, even though it makes use of a service-based architecture. If the service is implemented in terms of the domain model, then we've just negated, or at best muddied, the reason for having a service in the first place. Our pretty facade has sprung a leak, and one that's very difficult to patch. Our domain objects are now subject to possible misuse by front-end coders, who also, because they are now coupled to the domain model, will resist changes to it. Additionally, the domain model is subject to usage patterns for which the domain implementors didn't plan. These new usage patterns may break important invariants or constraints that service implementations were intended to enforce. Having lost control of the domain model, we also won't be as free to change the way we implement our services, say from a thin service implementation to a thick one. These are all basically the same problems that occur when we give clients direct access to the domain model with no intervening service.


Objects are recast at system boundaries for a reason: decoupling. The front-end of the system, in the majority of cases, needs only to pass us simple data structures, and to receive simple data structures in return. It does not need (nor does it really want, due to the responsibility that comes along for the ride) access to the full domain model.

Posted: Wed May 26 04:33:57 -0700 2004

/Cycling First High Grade Ascent of the Season

I decided yesterday that I should attack High Grade Road today. I got out to Deer Creek Canyon about 7:30, took a last minute whizz, and took off. I was pretty much alone at this point, and for that matter the whole climb; on the descent I passed a lot of folks coming up.

Anyway, getting onto my Trek 5200 after putting 120 commuting miles on the Serotta last week was a bit odd. The bikes feel and handle very differently (I'll write about that sometime). As I started climbing Deer Creek Canyon road I noticed that I didn't feel all that strong - as a matter of fact I felt pretty weak. As I was to find out, the problem wasn't me, it was the (roughly) 10mph headwind adding to the effort. That, and the fact that I'm a slow warmer-upper, combined to make for some suffering in the first couple of miles. It was bad enough that I was crafting a plan to turn around when I reached the High Grade turnoff. However, at some point I noticed that I wasn't breathing hard any more, and I was actually fairly comfortable, though moving pretty slowly.

The High Grade climb itself was without incident, except that my left knee started complaining on a particularly steep pitch that I'd climbed standing. Once I backed down a gear or two and sat down, I was fine, and no more complaints from the knee the rest of the ride.

While on High Grade, I decided to just ride to the Pleasant Park school, at the top, and double back rather than continuing into Conifer. Two reasons for that: this was my first big climb of the season and I felt my knees deserved a little break, and it would save a bit of time. The descent was uneventful, but a little hair-raising due to all the winter gravel strewn about.

My bottom bracket has been creaking for the last month or so, and was really annoying on this ride, so on the way home I dropped the bike off at the LBS to have the pull the BB and regrease it. I want the bike to be ready to rock when we head to KY to do the Horsey Hundred in Georgetown.

Posted: Sat May 08 10:28:59 -0700 2004

Thanks for visiting! Send comments to Mike Thomas.