I was in a meeting today where a discussion was happening about the benefits of using Hibernate in an enterprise Java application. I pointed out that with Hibernate the options are provided to call stored procedures, have Hibernate generate SQL for you, etc. The main point was that it provides a lot of flexibility and that we should be using the best tool for the job whether thats a stored procedure, dynamic SQL, etc.
At my current employer the past standard was “all data access is done as a stored procedure”. It is also important to note that Hibernate is not popular. The current standard also is “all data access is done as a stored procedure” but various projects have been straying from that standard. When it was stated that we should use the best tool for the job some people present in the meeting took exception to that and became angry. It was noted that SQL Injection attacks were very easy where dynamic SQL is involved (read: where Hibernate is being used).
SQL Injection certainly can be a problem but it really depends (like anything else) on the environment. In a system where form fields are being sent essentially unchanged to the database this is a large concern. In any modern enterprise system it isn’t likely it will be a problem (thought it certainly should be thought of). Where is the SQL Injection going to happen? There should be validation rules for any form fields. For performance reasons PreparedStatements should be used which also has the nice side effect of dealing with SQL Injection issues (why? because you’re not building a where clause…you’re just plugging in a parameter). Drivers could also deal with this issue with proper escaping of special characters in string parameters.
Needless to say there are a lot of ways SQL Injection attacks can be prevented in an enterprise application. It isn’t a problem that needs an inordinate amount of time to deal with and it certainly isn’t a reason someone shouldn’t choose Hibernate as the data access tool of choice in an enterprise application. This brings me back to the title of this posting ‘Complacency on “Corporate Standards”‘.
Just because something has been a standard way of doing something doesn’t imply that the standard shouldn’t be reviewed occasionally. If it has been years (and in this case it literally has been years) the policy most certainly should be reviewed to see if there are better options given how quickly things change in the IT business. I have been programming professionally for about 15 years now and in that time the *only* time when stored procedures were popular and the way to do something was 15 years ago. I think it’s pretty obviously with the rise in popularity of frameworks like Hibernate (on the Java side), and Rails, etc. that time is long gone. That isn’t to say that a stored procedure shouldn’t be used but it shouldn’t be the only option.
The old man yelling at kids to get off his lawn? That was this situation. It’s time to tell the old man to move aside and let some new ideas through.