Hacker News Reader

Comment by thomascgalvin | Hacker News Reader

> Lets take for example ORMs and Hibernate in particular. I can't tell you how many times I've seen horrors related to ORMs / Hibernate ...

My teams don't use ORMs anymore. I've found that all of the time we "save" by not hand-writing SQL is instead lost fighting with the ORM, and problems with SQL are a lot easier to Google.

I've also found that the ability to swap databases quickly is almost totally unimportant. 100% of the time we're targeting SQLite and PostgreSQL. I don't need a few extra thousand lines of code so I can theoretically support SQL Server running on a toaster in some kid's dorm somewhere.

View on HN

I'm actually a big fan of myBatis [0] for this very reason. You still write all the SQL, including stored procedures. All it does is map objects to input parameters, and map result sets to objects. Which is awesome, because that's the part of database processing that is actually tedious and sucks. Writing SQL is not.

I think StackExchange's Dapper [1] works similarly in the .NET world.

[0] https://github.com/mybatis/mybatis-3

[1] https://github.com/StackExchange/Dapper

this is pretty close to the sweet spot for me. being able to map rows to object easily + being able to easily compose queries are what i want from my 'ORM'. if your SQL layer doesn't support chaining conditions you end up writing it anyway so being able to do .and(condition).and(condition).and(condition), etc is pretty useful. ActiveRecord in rails comes close to this but it also manages relationships as well which makes things a bit more complicated but not as complicated as what hibernate or other ORMs do.

Having worked on many systems like this, I generally don't really consider it to be better. Most of them just introduced different edge case behavior than Hibernate.

Though, I generally prefer a non-religious approach to ORM mapping anyway. Use Hibernate for the stuff that it is good at. If you find it awkward for some particular service, don't be afraid to grab a DB connection and do a bit of SQL (maybe even using Hibernate's powerful rowmapper functionality) when it is easier.

Any ORM is going to be a little rough in some cases (even ones you write yourself) and none fit all problems perfectly.

> Use Hibernate for the stuff that it is good at.

Sure, but that's a bit circular. I find that a sensible default is to write the code to match the data, not abstract the data to fit the code. Because, if nothing else, you'll want to understand that data with another language or framework. If it's a one-off Java project that will get thrown away in a few months, whatever is fine, but most Java applications (especially enterprise Java) aren't throwaway projects.

Do you know what works in pretty much every language? Do you know what will be supported in 30 years? SQL queries.

Hibernate is good at some things, but if we think in terms of product lifetimes and not sprints, I think SQL is a much lighter dependency.

I would actually argue that raw SQL in Java has worked pretty poorly overall ever since it was introduced. The APIs have gotten better, and will probably continue to.

But you know what has consistently provided a nice abstraction that works really well for 90% of cases (even if you start with DML, as you should)? Hibernate :)

I've used plenty of homegrown frameworks, and they just never are quite what their originators crack them up to be.

I think every commercial system that I have worked on has had a database abstraction layer of some form, ignoring the fact that an RDBMS with SQL was a better abstraction layer than what they came up with.

It doesn't help that the common advice to securing a database application is "don't, it's too hard to secure databases, just write another application to talk to the database application, and secure that."

A database is just another application. SQL is just another Turing-complete programming language.

How do you make sure that what you are writing is secure?

What difference does an ORM make?

ORM's by and large do protect your from SQL injection attacks.

By using prepared statements, which you can use as well.

They don't. All decent ORMs have a layers architecture, and it's usually some "query builder/processor" or "DAL" or whatever that sits under/above the ORM your app uses (and can usually also be used directly, but has a horrible API since it's not optimized for this use case) that does the simple but tricky tasks of parameter sanitization and all...

The ORM is just an big fat thing that sits on top, and from which you only use 10% of the functionality it provides, but in theory each app uses a different 10% so it justifies itself...

ORMs can be ok... as long as you don't build business logic on top of and inseparable from it!

(As an example of horrible use of ORMs: some frameworks have ORM systems with an events system on top... god have mercy on your soul if you make the mistake of using this system to implement business logic, and end up with it accidentally depending on db connection and caching details, and not having time to refactor when you realize this! ...but if you avoid the trap, you can reap the benefits of the functionality that the ORM provides, while moving your logic at at a whole different layer of the app - hint: just invent a new "XBizLogicServices layer" or whatever and not import framework stuff into it if you can't find a better design, it will at least be easily testable.)

I wasn't defending ORM's.

I was just pointing out that if you use one you do receive protection from injection attacks. Just because only part of the ORM is actually performing the protection doesn't change the fact that you have it as a consequence of using the ORM.

You can also get the same protection by using a SQL library that supports prepared statements. But ORM's still provide that benefit.

Reply on news.ycombinator.com