4 ms·

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

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.

unclebucknasty 13y ago
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.
- lukaseder 13y ago
  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 http://www.jooq.org
  - unclebucknasty 13y ago
    >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. ;)
    - lukaseder 13y ago
      > 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": http://blog.jooq.org/2013/05/03/sql-query-transformation-fun-predicates-with-row-value-expressions/ http://blog.jooq.org/2013/05/03/sql-query-transformation-fun...

unclebucknasty 13y ago

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.

lukaseder 13y ago
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 http://www.jooq.org
- unclebucknasty 13y ago
  >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. ;)
  - lukaseder 13y ago
    > 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": http://blog.jooq.org/2013/05/03/sql-query-transformation-fun-predicates-with-row-value-expressions/ http://blog.jooq.org/2013/05/03/sql-query-transformation-fun...