Var-Arg DAO Finders
Tuesday, 8. August 2006, 13:21:39
Almost every Java DAO class I have seen contains finder methods with unfortunate ugly and lengthy names:
This has always been distracting to me. Once I see a class with such stupid method names, I try my best to keep myself away from it. I DON'T LIKE LENGTHY METHOD NAMES! I DON'T LIKE METHODS WITH LARGE NUMBER OF ARGUMENTS (unless, well continue reading...!) It's the sign of a bad design. It might be an inherent weakness of the host language, but that doesn't solve anything. Some languages support named arguments which is just fine and pleasant to work with:
However, the declarations still remain just as lengthy. But thanks to variable length arguments introduced in Java 5, it's very easy to write finder methods that not only are concise to declare and invoke, but also more generic and flexible. The idea is to pass a comma separated list of arguments as a string followed by the arguments themselves:
This even eliminates the need to have more than one equity-based finder method in your DAOs. A negative side-effect is the loss of type-safety, but I belive, overall, it won't hurt that much and is neglectible.
In a follow-up post, I'll provide a simple JDBC DAO implementation as well as a more flexible finder that not only supports equity comparision, but also LIKE, between, less than, greater than, and more operators as well.
Neat! Izhn't dish jusht sho shibit?
- findByNameAndFamilyName
- findByPositionAndDepartment
- findByMonthAndCategoryAndTitle
- findByBlahBlahDamnBlahBlahAndGodDamnBlahBlah
This has always been distracting to me. Once I see a class with such stupid method names, I try my best to keep myself away from it. I DON'T LIKE LENGTHY METHOD NAMES! I DON'T LIKE METHODS WITH LARGE NUMBER OF ARGUMENTS (unless, well continue reading...!) It's the sign of a bad design. It might be an inherent weakness of the host language, but that doesn't solve anything. Some languages support named arguments which is just fine and pleasant to work with:
- find(name: "James" familyName: "Gosling")
However, the declarations still remain just as lengthy. But thanks to variable length arguments introduced in Java 5, it's very easy to write finder methods that not only are concise to declare and invoke, but also more generic and flexible. The idea is to pass a comma separated list of arguments as a string followed by the arguments themselves:
- find ("name, familyName", "James", "Gosling")
This even eliminates the need to have more than one equity-based finder method in your DAOs. A negative side-effect is the loss of type-safety, but I belive, overall, it won't hurt that much and is neglectible.
In a follow-up post, I'll provide a simple JDBC DAO implementation as well as a more flexible finder that not only supports equity comparision, but also LIKE, between, less than, greater than, and more operators as well.
Neat! Izhn't dish jusht sho shibit?
WIDGETIZE
Anonymous # 8. August 2006, 19:44
I agree, this is a great technique. More here:
http://blogs.opensymphony.com/plightbo/2006/08/var_args_and_javas_lack_of_nam.html
Anonymous # 9. August 2006, 14:52
You lose compile time checking though.
Anonymous # 9. August 2006, 15:48
My thought is to provide a simple bean syntax (which obviously doesn't exist in Java today except sort-of in annotations), then you could do things sort of like JavaScript. For instance: 'find(%(name = "James, familyName = "Gosling"))' or something like that.
Behrang Saeedzadeh # 10. August 2006, 12:19
You're right, but I have mentioned this in the post: "A negative side-effect is the loss of type-safety, but I belive, overall, it won't hurt that much and is neglectible."
@Tom
I agree. Adding such a feature to Java could make some of those LoC's go away and make writing programs in Java less tedious.
Behrang Saeedzadeh # 10. August 2006, 12:29
ParaNamer looks cool and it kind of makes this technique applicable to regular Java objects rather than SQL queries, if I have understood it right.
Anonymous # 24. August 2006, 03:07
Ugh... And how do you tell that you've got a prepared statement that can handle those? Or check at runtime that the field names you're passing in make sense? This is an ugly hack to compensate for not working with a better API.
I personally just use the Hibernate Criteria object for this... dynamically populating a Criteria object at runtime is simple and it manages the PreparedStatement handling and checks that the criteria properties are really there on the object you're querying.