5 ms·
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 Hiber
by jsight 9y ago
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.
- humanrebar 9y ago> 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.
- jsight 9y agoI 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.