Javalobby - Comments for "People are still writing straight JDBC Code?" Comments for "People are still writing straight JDBC Code?" en Many people who are writing <!--paging_filter--><p>Many people who are writing plain JDBC are switching over to using&nbsp;<a href="" target="">jOOQ</a>&nbsp;for typesafe SQL.</p> Wed, 20 Nov 2013 06:22:17 -0500 comment 107161 at This application combines the <!--paging_filter-->This application combines the two into a single applet and adds the capability to specify the graphic returned. Listing 9 shows the complete application. <a href="">ruby on rails</a> Wed, 07 Sep 2011 09:19:26 -0400 JessieMear comment 55847 at Hibernate itself isn't bad, <!--paging_filter-->Hibernate itself isn't bad, as long as you observe some rules as soon as you are working in bigger scenarios: <ol> <li>Do not integrate the DAOs directly into upper layers as first-class values. The problem in both scenarios is that the structure of DAOs usually does not match the exact requirements of the usecases in which your are working. Rather write your own Types which match the usecase, and do not try to "hack" the DAOs to match it by a series of if's and elses. There is a large difference between the UI view and the DB structure, which can rarely be translated directly. </li> <li>Never use DAOs as data transfer objects! The worst problem with hibernate-daos is that you can never rely on lazily-loaded values. The type has a getter for a list of relation objects, but who says that these have been read? This was a common source of bugs in my applications. </li> <li>Relations Again: IMHO, OR-Mapping should not map these things directly anyway into the beans. Relation-Fetching can eat up a lot of performance and it is very complex. I prefer beans without relations and manual querying for the relations. Also, as seen in the previous point, it cannot be transparent and then can be source of bugs.</li> </ol> Mon, 14 Feb 2011 05:40:38 -0500 snadric comment 46057 at For people looking for a <!--paging_filter--><p>For people looking for a simplier alternative to Hibernate/JPA they could have a look at <a href="">Ebean</a>.</p><p>The main simplification is that is uses a &quot;session-less&quot; API - so the developer doesn't need to worry about attachment/detachment and the lifecycle of the Hibernate session (or JPA EntityManager).</p><p>It has a few other interesting features such as &quot;Autofetch&quot; which is automatic query tuning based on profiling of your application.</p><p>Anyway, just thought I'd mention it here for those people looking for a simplier alternative. </p> Sun, 13 Feb 2011 19:06:19 -0500 rbygrave comment 46029 at I could not agree more with <!--paging_filter--><p>I could not agree more with Jilles van Gurp, all of his points are valid and resonate with my experience as well. What is interesting, I have learned Ruby on Rails a few years back, and was thoroughly impressed by ActiveRecord - this is a Ruby ORM for RoR. Experience using it was a refresher after heavy handed frameworks in Java, so much so, that after waiting for some time for someone to implement this in Java, I decided to do this myself. If anyone interested in a truly lightweight Java ORM, you can try <a href="">ActiveJDBC</a>. I will be publishing an introductory article on DZone soon. Some initial blogs can be found here: <a href=""></a> and here: <a href=""></a></p><p> I tried to strike a good balance with the API simplicity, performance of the ORM layer, and especially making it as intuitive as possible. </p><p>enjoy</p><p>igor </p> Sun, 13 Feb 2011 03:27:17 -0500 ipolevoy comment 46019 at  For those claiming ORMs <!--paging_filter--><p> For those claiming ORMs aren't the problem but people not reading the documentation is, please stop.  Most projects simply don't benefit from an ORM, not matter how well you know said ORM.  Period. And that's why people still write JDBC code and SQL.    I would suggest to most, to give groovy a look.  It pretty much can eliminate most of your broilerplate JDBC code.  I've moved from iBatis to Groovy for SQL and I love it.  Personally, I've always hated hibernate(maven and spring are on my hate list too).     The author should do a post titled &quot;Why are you using an ORM, when you could use iBatis or Groovy&quot;. </p><p>&nbsp;</p> Sat, 12 Feb 2011 23:00:53 -0500 sybrix comment 46015 at I agree that having an <!--paging_filter-->I agree that having an understanding of the behind the scenes knowledge important and I would advise developers to invest time in this. <p> However, there are fundamentals in evolution at work here. Would I trust building my application on Spring, written by experts, used by millions in countless applications world wide, or on your proprietary implementation? </p><p> Should we always all have knowledge of lower level details? At some point you need to build upon something you don't have full understanding of and can trust. For example what do you know about hardware design? Does it really matter relative to what you know at the higher level? </p><p> The abstraction point is very important here. Spring JDBC provides what JDBC does but at a higher abstraction by hiding boiler plate, and therefore should always be favoured. ORM's address different concerns so cannot be taken as a straight form of substitution for JDBC.</p> Fri, 11 Feb 2011 18:33:39 -0500 knoxl comment 45989 at In my experience, iBatis(now <!--paging_filter--><p>In my experience, <a href="">iBatis</a>(now MyBatis) is a great alternative to Hibernate/JPA when you don't want to go the JDBC route. I've used it with great success in several projects in the past, you should give it a try if you haven't. </p> Fri, 11 Feb 2011 16:48:40 -0500 rsmaniak comment 45979 at I totally agree with everyone <!--paging_filter-->I totally agree with everyone here about not trusting Hibernate. One of my projects was to build middleware for multiple front end. I was using Tomcat with Hibernate and I tried to make it lightweight enough on everything else and so my middleware could survive the non-functional requirements because it was sitting on a 1U Dell Dual Core 2GB. I was believing it that it should have plenty of power to handle all requests because I made all requests from front ends all lightweight.<br /><br />Yes, it worked. BUT, it crashed.<br /><br />I thought the story ended when I tested so many times, end-to-end and UAT. Everything went well. But after the weekend, users reported "no response" from front end on Monday. I spent so much time on investigating it and finally I found that it was a Hibernate memory leak issue. Weird, isn't it? The problem was, when there were requests coming continuously, the memory were reused and so server and hibernate were considered active. However, when there were no requests coming in for certain amount of time, the JDBC pool was trying to shrink down to minimum pool size and that triggered the memory unable to release error in Hibernate because it had references to it. It was tracked as major defect in major release of 3.2.4 or something. That was a very bad one! Fri, 11 Feb 2011 10:01:29 -0500 hksduhksdu comment 45963 at Yes I do write JDBC code. I <!--paging_filter-->Yes I do write JDBC code. I guess it is not so painful in Scala :-) Fri, 11 Feb 2011 06:07:51 -0500 jankotek comment 45943 at The reasons why people fail <!--paging_filter--><p>The reasons why people fail with frameworks are usually always the same: They do not read the documentation well enough and /or lack the theoretical background, then they jump straight to the implementation, usually without automated tests, so they see the wrong results just when they thought they were almost done.</p><p>ORMs are complex by nature, and always will be.</p><p>Of course, i'd prefer a working application with &quot;plain&quot; JDBC  over a non-working (buggy) application with an ORM, but the cause is not the ORM or any framework as such, but the lack of skills in the development team.</p><p>Pick your frameworks wisely, based on evalution and the skill level/experience of the team, not on marketing. The choices made that have lots of consequences are also known to be part of the architecture.</p><p>This is not just the case with ORM, but also applies to WebFrameworks, build tools, DI Frameworks, etc. pp.</p><p>Some frameworks have their own set of problems, like EJB 2.x and JSF 1.x. </p><p>For most green field projects i use an ORM, but using iBatis/MyBatis for brown field projects with an existing schema often has advantages ime.</p><p>&nbsp;</p> Fri, 11 Feb 2011 05:13:15 -0500 mgira comment 45941 at Even though I am an avid <!--paging_filter-->Even though I am an avid Spring proponent, I'll disagree. Most of us are proud for our profession and skills. Your article treats the average developer like an idiot who should only rely on canned solutions <i>made by the smart people</i>. This is the same annoying attitude Hibernate people had a couple of years ago. Fri, 11 Feb 2011 04:13:56 -0500 agnus comment 45939 at Depends on the scope of the <!--paging_filter--><p>Depends on the scope of the application and the exact nature of the sql. For complex model and dependency management it is worth the effort to invest in an ORM, but if you have simple table (or several) with simple flows then why to put ORM and its adjoining complexity? In many cases this code also reside in its own project (let's say a war that provides some services) and for me there is no reason to increase its size just for the sake of ORM.</p><p>Using Spring and JdbcTemplate (which is what we do), takes almost all the pain if handling connections, statements and all the preparation and clean up which are the main problem of using jdbc. </p> Fri, 11 Feb 2011 03:56:10 -0500 davidmate comment 45933 at Personally these two concepts <!--paging_filter-->Personally these two concepts should be addressed separately <p> 1. There seems no reason to favour straight JDBC when you have Spring's excellent JDBC support which hides the resource management and general gunk and comes also with great transactional support. I would always use Spring over straight JDBC </p><p> 2. ORM's have their place but they are not the solution for all problems. I wouldn't say there are just edge case there are simply lots of cases where ORM's don't fit.</p> Fri, 11 Feb 2011 03:51:28 -0500 knoxl comment 45931 at The illusion of Hibernate is <!--paging_filter-->The illusion of Hibernate is that it pretends that you don't have to care about the database to deal with it, which is completely false. At least, with JDBC (and the help of annotated transactions, Sproing JDBC templates and RowMapper), you're aware of what you're doing.<p>Hibernate or JPA can be great productivity tools, but they have to be used very cautiously, under the supervision of experienced people. As a technical team leader, I'd certainly recommand it neither for a junior team, nor for a big expericeed team. </p> Fri, 11 Feb 2011 01:27:46 -0500 FunkyFab comment 45927 at Why not? <!--paging_filter-->Why not? Thu, 10 Feb 2011 21:14:28 -0500 woongiap comment 45923 at I too have had a terrible <!--paging_filter-->I too have had a terrible experience not only with Hibernate, and with every other ORM out there, when trying to do anything remotely advanced or complex. Most are brain dead and impose naive schemas that are not optimized for anything other than small scale applications. Hibernate doesn't play nicely with transactions at all, it doesn't work reliably with caching causing all kinds of weird errors because of extremely poor cache management. I do agree that writing alot of the boilerplate code is error prone and messy and Java is nothing if not full of boiler plate code. I don't think moving the boilerplate code to Spring is any better, it is just as messy. I created the following project to do the boilerplate for me. it is moving to GitHub just as soon as I get a chance to update it and move it. Thu, 10 Feb 2011 18:42:16 -0500 JarrodRoberson comment 45919 at I still find JPA/Hibernate <!--paging_filter--><p>I still find JPA/Hibernate very convenient for CRUD-like screens. And I agree with the previous commenter: 80-90% of the people I worked with just didn't understand what they were doing with Hibernate. </p><p>&nbsp;</p><p>From my experience it's better to use:</p><p>- ORMs for CRUDs (eg administration sections of your app)</p><p>- SQL/StoredProcs for  front end stuff (eg parts with lots of hits or searches) </p> Thu, 10 Feb 2011 18:34:44 -0500 fabmars comment 45917 at That's what you usually get <!--paging_filter--><p>That's what you usually get for using tools that you don't understand / know well enough to use them correctly. As a junionr I saw usages of Hibernate implemented by seniors in such a way that I wanted to cry - there was no understanding of anything, and it was because nobody ever read anything on the topic. Was this ego? Lack of time? I have no idea; what I know is that the code was utter nonsense, which was not fault of the tool, but of the people who used it incorrectly. </p><p>As for the auto-generated schema - nobody on the Hibernate team ever said you should use it for production. It is only natural to employ a DBA for 2 straight days / weeks to pimp it up.</p><p>That being said, I prefer other tools to Hibernate. </p> Thu, 10 Feb 2011 15:53:45 -0500 ws comment 45913 at I actually switched back from <!--paging_filter--><p>I actually switched back from JPA/hibernate to raw JDBC after observing the following things:</p><p>1) People in my team were blindly trusting Hibernate to do the right things. It wasn't and it proved very hard to fix &amp; debug on multiple occasions. We had a long succession of very obscure bugs that essentially boiled down to hibernate doing things we did not intend or not doing things we actually wanted it to do.</p><p>2) The amount of magic was such that people were assuming things to happen that actually weren't happening at all or at the wrong moment. Things like transactions for example. Just because it has an annotation, doesn't mean you've done your job. When the magic stops working you have a problem.</p><p>3) It was painfully slow without any obvious reason. Part of the reason was that an optimized database schema looks quite a bit different from what hibernate produces from what looks like an innocent little data model.  </p><p>4) People were thinking they were doing OO development instead of database development. That's an illusion that hibernate is designed to provide but if you fall for it it will prove to be fatal. We fell for it and our data model turned into a ridiculously normalized mess with way too many tables. Hibernate + junior engineers is a disastrous combination. </p><p>So we did the following:</p><p>1) we re-developed the worst offending code from scratch</p><p>2) we used plain old jdbc only (very refreshing experience, it's not complicated at all).</p><p>3) we kept the data model &amp; database schema for compatibility reasons</p><p>4) we offloaded most our complex querying to solr. This gave us a massive boost in performance &amp; scalability as well as ease of use. </p><p>This fixed our performance and complexity issues in a pretty dramatic way. Also , the resulting code is quite small &amp; simple. I haven't had to touch it in months since it just works. </p><p>We could have probably achieved the same results with hibernate and a complete redesign. But I don't believe the added complexity is worth the magic. I'm a strong believer of keeping things small and simple. </p> Thu, 10 Feb 2011 15:09:10 -0500 jilles comment 45907 at In one of my scenario where a <!--paging_filter-->In one of my scenario where a product engineer is looking for an app that can take his command sent from his machine through network, and being able to save into database. I used Tomcat with pure JDBC code to do that because Spring and Hibernate frameworks actually give trouble of ORM overheads. Thu, 10 Feb 2011 14:59:55 -0500 hksduhksdu comment 45905 at Take it from someone who's <!--paging_filter--><p>Take it from someone who's used Hibernate for over 5 years, ORMs are the crap. Ted Neward had it right:</p><p>&nbsp;</p><p>I personally recommend the following combination:</p><p>1. Plain JDBC</p><p>2. querydsl-sql for type-safe queries:</p><p>3. MyBatis Migrations or Flyway Migrations for database versioning</p><p>&nbsp;</p><p>ORMs might seem easier/faster at the beginning but you'll end up with a higher learning curve and more edge cases than the above combination. Your overall productivity will actually be higher using straight JDBC and you'll end up with simple code.</p> Thu, 10 Feb 2011 14:55:39 -0500 cowwoc comment 45901 at