7

I have to begin a medium-sized project in Java, but I'm not a big fan of ORMs in general so the question is: Should I design the project with an ORM in mind (for later use) or not?

The RDBMS is Oracle 10g and the queries will be very coupled to Oracle syntax/functions (i.e. text, mining, CONNECT BY, etc...).

Thanks a lot.

JoshJordan
  • 12,676
  • 10
  • 53
  • 63
ATorras
  • 4,073
  • 2
  • 32
  • 39
  • People who don't like ORM do probably use it poorly. Here's an old article of mine on what to take care when using ORM: https://www.linkedin.com/pulse/get-know-your-orm-avoid-bad-habits-balazs-hideghety/ – baHI Dec 11 '19 at 17:57

11 Answers11

11

You might want to look at this earlier question which discusses the benefit of ORMs: What are the advantages of using an ORM?

The most relevant part (taken from the accepted answer):

If you have complex, hand-tuned SQL, there's not much point in using an ORM.

If you are constantly reaching past the ORM and writing your own SQL, the ORM might just end up getting in the way.

Community
  • 1
  • 1
Aaron Maenpaa
  • 119,832
  • 11
  • 95
  • 108
  • What does "complex, hand-tuned SQL" mean? I thought the ORM could handle anything you could do in SQL. – johnny May 05 '09 at 17:11
  • An ORM being able to handle *anything* you could do in SQL particularly when you are considering a specific SQL (in this case Oracle's). If you need to make use of Oracle specific features, you will probably need to write at least a few of your queries in SQL rather than the ORM's object query language. – Aaron Maenpaa May 05 '09 at 17:52
  • The most common places where I've had to reach past the ORM and write my own SQL have been reports. Some reports can get quite complex, and I don't think any ORM uses PIVOT yet either. – Min May 05 '09 at 20:07
  • 3
    @johnny: there are many data related problems which come up that require hand-tuned/created sql to effectively solve. Further, when you can use the advanced features of the particular database server you can generally solve these in a more efficient manner. – NotMe Jul 02 '10 at 14:50
5

Since Im not allowed to comment your post Ill comment like this(lack of points).

Would be good for the discussion WHY you dont like ORM.

Imo, I would go for it. And if you for some reason find a query that is slow by the ORM, then I would make it myself. Just because you use an ORM most of your tasks does not mean you have to use it for all. But yes, it would be preferred.

Carl Bergquist
  • 3,894
  • 2
  • 25
  • 42
5

I personally have found them (well, Hibernate) to be an incredible time sink. Far from saving time, I have spent way too much time trying to figure out what the hell it's actually doing under the covers. As others have mentioned, if your data model grows beyond a certain complexity, having another layer between you and the DB just creates more friction. If your data model isn't that complex, well, then you don't really need ORM anyway.

I do recommend having some sort of abstraction to keep SQL out of your Java code, but that can be done simply with a DAO layer and property files or whatever. Also tools like IBATIS or Spring JDBC can be helpful, since you can still write your own queries, and just use the framework to help with all of the boilerplate code for shuffling data between JDBC and your Model objects.

PS: amusing side note. In my office we actually have a framed picture of Gavin King that we all curse in effigy. "Hey, it's your turn to deal with today's Hibernate issue, so here's Gavin." :-)

George Armhold
  • 30,824
  • 50
  • 153
  • 232
  • This is exactly how I feel to. Hibernate introduces more problems itself than it solves. JDBC with SQL builder is the way to go in my personal opinion. Take a look in this light ORM with SQL builder: http://mentabean.soliveirajr.com – TraderJoeChicago Sep 12 '11 at 11:51
  • @TraderJoeChicago well, if you don't know how to use it properly, then yes. but I do use complex OO models for generating PDF based on various rules, also I do have a type-safe way for querying DB! – baHI Dec 11 '19 at 17:52
4

Another advantage with an ORM is that it will look very good on your CV. Most jobs being advertised today (at least Java devs) require some knowledge of ORMs. So if you have the chance to work on a project I'd choose Spring and Hibernate as it will really boost your CV.

I thought the link to the other question covered the technical benefits rather well so I'll not say anything about them.

willcodejavaforfood
  • 43,223
  • 17
  • 81
  • 111
  • 7
    So will putting down "Hard core Oracle developer" and being able to articulate why in some situations you don't actually want to abstract away the $10,000 per CPU database engine that you're using just in case you want to swap it out for sqlite3. – Aaron Maenpaa May 05 '09 at 16:52
3

I personally prefer to be as close as possible to SQL, so I would use iBatis, JOOQ or MentaBean. MentaBean by the way offers a approach as close as possible to SQL while at the same time offering a lot of help with the boilerplate JDBC code.

TraderJoeChicago
  • 6,205
  • 8
  • 50
  • 54
2

Yes. ORMs can take a lot of burden off of an app developer; at the very least, designing with them in mind shouldn't add much burden to the design, and can help significantly in the future if you decide to go with an ORM.

Paul Sonier
  • 38,903
  • 3
  • 77
  • 117
2

An ORM intentionally decouples your working objects from the database, creating an abstraction (inevitably with leaks). So you'd just end up tunneling back through to restore what you'd intentionally eliminated.

If a lot of your application is intentionally implemented in the database, then an ORM just adds noise to your signal - and attenuates the signal.

dkretz
  • 37,399
  • 13
  • 80
  • 138
1

ORM: Yes for any corporate like software, where data is complex...multiple levels, tables, layers... But even here a good mix of NHibernate and EF6 and database views are advised.

No for any special apps. like measurement and where you need to save really a lot of data, but without data complexity

With ORM there are multiple possibilities, all depends what you want.

As a real ORM mapper I strongly recomment NHibernate and Fluent NH mappings. You need a lot of research to put together a nice architecture, but then nothing stands in your way. With minimal compromises you get real flexibility.

EF6x (core is not prod.-ready IMHO) is called an ORM, but what it generates is more closer to a DAL. There are some thing's you can't do effectively with EF6. Still, this is my favorite tool for a read-model, while I do combine it with NHibernate (where NH I use for a DDD/write model).

Now to performance - its always pro and cons. If you deep deeper into ORM architecture (see my article: avoid ORM bad habits) then you will find intuitively the ways to make it faster. Here's my another article on how to make EF6x 5x faster (at least for read situations): EF6.x 5x faster

baHI
  • 1,510
  • 15
  • 20
1

OR-mapping can indeed be a problem for your database-specific SQL. However, some concepts of OR-mapping are very powerful and will make it easier to interact with your database. Some of those concepts common to many OR-mappers are:

  • Code generation for your database schema.
  • Type-safety (by some ORMs)
  • More robust variable binding than that provided by JDBC
  • SQL composition by objects to avoid SQL syntax errors

A good tool for your task could be https://www.jooq.org, which allows you to create any SQL you want (including nested selects, unions, complex joins, aliasing, stored procedures, UDTs, etc).

Disclaimer: I work for the vendor

Lukas Eder
  • 211,314
  • 129
  • 689
  • 1,509
1

It depends...

And you don't have to use an ORM for every DB access...

pgras
  • 12,614
  • 4
  • 38
  • 46
1

Like others have mentioned; if you are heavily (relational) DB dependant, ORMs give litle and just add not-so-useful abstraction. But most importantly: do you (want to) deal with data as Objects or not? If yes, ORMs are designed for that. If not, why bother. And you can add ORM later on if need be -- may take bit more time than upfront, but doing the reverse (weed out Hibernate after it just gets in your way...) is much worse.

But there are also differences between ORMs; iBatis might be better fit than Hibernate, for example (there are other questions for this particular topic).

StaxMan
  • 113,358
  • 34
  • 211
  • 239