3 ms·
IMO people discussing this topic really need to clarify what type of applications they are working on because the cost/benefit analysis changes quite significan
by nodamage 6y ago
IMO people discussing this topic really need to clarify what type of applications they are working on because the cost/benefit analysis changes quite significantly based on use case. If you're building a web-based reporting tool where you simply query records out of a database to dump to HTML and your objects are short lived, you might not get as much value out of an ORM compared to a client-side app where objects stick around for the entire lifetime of the application and you have to worry about things like object identity and staleness.
- 3np 6y agoI'd also add that if it's a community-based open source project, there can be great benefit in more safely supporting a bigger set of database engines (e.g. sqlite for the simple entry-level, postgres et al for the more serious) at the cost of some performance overhead. If it's a performance-critical in-house service where you have full control of the deployment and can tailor it to your use-case, it's a completely different story.
- midasz 6y agoWe have to support both MySQL and MSSQL so Hibernate has been mostly great for that. For really simple queries it's also nice to be able to write "findAllBySomethings_IdAndPropertyIsNull" etc instead of writing a SQL query. Been there, done that. Though I have to admit I do check what queries Hibernate produces to make sure it's not doing some funky stuff that's not really needed (as a result of a mistake of my own, mostly) Edit: It has come to my attention that it is ofcourse Spring Data that offers those named queries. Still see nothing wrong with hibernate since I still only have to write it once and I'll be relatively safe supporting both db systems.