The problem with homegrown DB interfacing stuff is that no other developers want to learn to use it, instead of standard using ORMs. Fine if you are a lone wolf but using a 10 year old homemade DAO layer wouldn't fly in a team.
Perhaps, but I think that's actually part of the fallacy here. That is, this mindset "let's all adopt and learn to use something obtuse and wildly overly-complicated, so that it at least becomes a standard that we can use (and further propagate) elsewhere." I noticed, for instance, that you didn't refute the ugliness of the OP. Your reply instead seems to be saying, "at least we can get the team to use it".
Now, this is really reminding me of EJB. Seriously, it's how we end up with these insane "standards", the embrace of which is probably at least partly responsible for Java's reputation as an inefficient language in which to develop.
And, there are certainly ways to approach code generation in a team environment, especially if the team was willing to put a fraction of the effort into such an approach, as they would put into learning and maintaining something like the OP. At the end of the day, you just need to get data in and out of the DB. Whether it is ten years old or homegrown shouldn't matter so much if it is clean, easily maintained, and efficient. Teams adopt project-specific patterns all the time for other parts of development. Why not for the DB access?
But, I just offered up my solution as a way to say that, in all of these years, I have yet to see a truly attractive alternative to something homegrown and "old". Many seem to agree as here we are with yet another proposal. But, things seem to be getting worse, as the OP is an example that borders on parody of previous offerings. Dynamic proxies and CGLib? Really?
When I read the title, I thought maybe someone had nailed it. But, we start with ugly, somewhat declarative code that surfaces SQL syntax, pass around some function names, throw in some mapping, get some dynamic proxies in the mix and, oh yeah, you're also gonna need CGLib, etc. I literally thought it was a joke. Then, I come here and the first comment is "This looks really nice".
So, aside from what I have decided to do to solve the problem, I would just ask why the OP approach should be considered a viable alternative and why we favor coalescing around such complicated anti-patterns instead of guiding our "teams" toward saner choices that work.
I can see what you mean and I think you have a couple of valid points there. Developers tend to think that anything aged more than 5 years is automatically "legacy", and thus very bad. They rewrite things from scratch with the next fancy-tech-du-jour, just to make the exact same mistakes again.
I've worked on a medium-sized 12-year-old "legacy" E-Banking system and it was just awesome to learn how the "old masters" had been coding so many years ago.
Nonetheless, JDBC is a low-level standard, JPA a high-level one. Both with their merits. However, there is room for a solution in between
> When I read the title, I thought maybe someone had nailed it.
If that's what you're after, then do have a look at jOOQ: http://www.jooq.org
>They rewrite things from scratch with the next fancy-tech-du-jour, just to make the exact same mistakes again.
Exactly. That is certainly part of it. There is a tendancy to replace one thing with another, simply because we can.
>However, there is room for a solution in between
Making improvements, abstracting ugly details, etc., can definitely be a good thing and there are certainly projects that do this well. What I have learned to dislike is "solutions" that make the problem worse and that abstract the problem rather than the solution. The data access layer seems to suffer disproportionately here. For instance, with the OP, we now we have ugly database code with added layers. Over-engineering at its worst. Not sure why we don't just ask the simple question: is this really the simplest, most efficient, maintainable, way to do x?
jOOQ: thanks for the pointer. I will have a closer look, but at first blush, it is quite a bit like what I wrote all of those years ago. Perhaps I should have just pushed to standardize it. edandersen would have it on his resume, and we wouldn't be having this discussion. ;)
> it is quite a bit like what I wrote all of those years ago. Perhaps I should have just pushed to standardize it. edandersen would have it on his resume, and we wouldn't be having this discussion. ;)
Could be. The idea isn't novel. But no one has (publicly) gone as far as jOOQ before, from my marketing research. Here's what I mean by going "far":
The reality is that most teams would rather another year of NHibernate experience on their resume than a year of "unclebucknasty's homemade DAO layer". It could be amazing but it's still a hard sell to a team with a career to manage and stakeholders who would like to be able to hire developers familiar with the frameworks used.
And thus continues the cycle of lunacy. I understand that you and some others believe this, and that's actually my point (partly). It's past time to reconsider the mantra, "let's standardize on a monstrosity". Again: EJB (and others) should have proven that it's better to have no standard, but productive dev teams.
Actually, though, I believe you overstate the desire of stakeholders to hire unthinking lemmings who demonstrate same by having the latest inane tech on their resumes. I have also hired and managed developers. When pressed during interviews, many had no clue how the tech worked beyond the happy path and would be lost at sea when presented with the slightest edge case.
Thus, I (and other smart managers) always cared about how our devs thought and solved problems, whether they were efficient and productive, how they adapted to new domains, general intelligence, etc. When you have that, you have devs who can get any job done, even if it means learning some inane buzzword dujour tech demanded by some poor, gullible, semi-technical "stakeholder".
The better engineering companies have long recognized this. You're not going to get a gig with Google because you have Nhibernate on your resume. You are going to get the gig when you prove that you're adaptable and smart enough to think through any problem thrown at you.
So, while I know it's fun for you to write "unclebucknasty's homegrown DAO Layer", I believe it's your paradigm that may be a bit outdated.
