>> Those that try to mix both usually find that they're >> running into problems with inconsistent data. > > Well, I am mixing both in the same app with success. > I use hibernate for the business logic stuff and jooq > for the reporting (mainly displaying tabular data with > sums, counts, averages).
As long as Hibernate entities and JDBC/Jooq data are kept strictly separate, or you don't write except through Hibernate, you're fine. Problems arise with code that deals with data from both sides of the fence, and that must write JDBC/Jooq-originating data. The other problem arises when you need to fall back from Hibernate to raw SQL. All of a sudden, you're working in SQL land and can't use all that representation hiding that Hibernate's naming strategies, UserType conversions, subtype embedding do. Essentially, you now have two data models, the SQL and the Hibernate one, and you need to keep both in sync in the developers' heads and in the schemas. As we all know, redundancy is bad, translated redundancy is worse. One can mitigate this by working with as raw data as possible with Hibernate, but then why use Hibernate :-) > Both tools have pros and cons. Hibernate is excellent > for efficiently loading graphs It helps, yes. > and has an interesting caching mechanism, I found the cache to be quite intransparent. You can't even get a list of the objects it holds. Not without using undocumented (i.e. unstable) interfaces anyway. > Hybrid scenarios can actually make sense if there is > enough separation (I wouldn't write services that mix > both in the same transaction). That's wise :-) > The biggest problem with ORMs is that people expect too > much from them. Many people think they can use them to > design a wonderful OO layer on top of their DB and stop > caring about SQL and the implications of the underlying > relational structure, which obviously lead to disaster. That's the first problem that people notice, but there are more: - It is hostile towards software that does direct SQL. For starters, the best schema design for ORM use is not the best schema design for SQL use, and vice versa. This is a nonproblem if the ORM-using software is the only software that will ever hit the database, but it starts to get problematic as soon as somebody uses an SQL commandline, or hits the database with a C wrapper. The problem is that people will want to access the database via SQL as soon as it becomes in any way important. - ORMs suck as doing mass data. Which is a consequence of - ORMs do not allow abstracting out processing logic (a foreign key condition, raw-to-representation transformations, aggregation logic) so that it can be used both in SQL and in Java; in the end, any logic that's needed in both worlds ends up written (at least) twice, once in Java and once (or more) in SQL. I'd like to see a library that allows me to construct such processing snippets, and either execute them using entity Pojos, or use them during SQL generation. (Something for Jooq 5.0 or later, I guess.) > Full object orientation always sounds nice, but not > everything is designed to fit in this paradigm, > especially MVC apps (typically HTTP-based webapps) > which require some kind of service orientation by nature. You can do MVC just fine, whether the data layer is OO or tables. This leads me to believe that the problem isn't in the use of the data, it's in the translation. A true Java-side representation of a database would be a bunch of Maps from keys to rows (or sets of rows). Unless you use the database just as a backing store for your object model. That's what Hibernate was built for, and this could work fine :-) -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
