When comparing Dapper vs Hibernate ORM, the Slant community recommends Dapper for most people. In the question“What are the best ORMs for C#?” Dapper is ranked 2nd while Hibernate ORM is ranked 6th.
Ranked in these QuestionsQuestion Ranking
Pros
Pro Very efficient and quick
Pro No need to roll your own conversion layer for the DataReader
Pro Similar performance to a raw SqlCommand with DataReader and parsing
Pro Makes it trivially easy to turn results into objects
Pro Makes it trivially easy to execute queries (scalar, multi-rows, multi-grids, and no-results)
Pro Makes it trivially easy to correctly parameterize queries
Pro Leader
There are countless great books and articles, it's taught at universities, and easy to find both skilled labour and advanced consultants .
Pro OSS
Fully open source, managed by the tought leaders in the Java community, decision making is open yet sponsored and legally backed by Red Hat.
Pro Advanced extension points
Hibernate ORM sports several advanced extensions such as Hibernate Search providing Lucene and Elasticsearch full-text search, Hibernate Spatial for GIS extensions, Envers for versioning and temporal queries, Hibernate OGM to use NoSQL as your primary datastore, advanced caching integrations and various connection pools.
Pro Actively maintained
Hibernate was very innovative from the beginning but is still very actively developed, improving significantly every release.
Pro High Performance
ORMs are typically not easy to scale yet the Hibernate team has been very sensitive to this topic, constantly optimising the code further and adding various advanced features to avoid paying a high cost for the convenience.
Pro Extensive integration points
Most other successful projects in the Java community integrate with Hibernate, making integration often a solved problem.
Cons
Con Not even slightly typesafe
If you make a typo in the SQL your CI server is not going to catch it, you'll have to hope it's caught during automated UI or functional testing.
Con A pain to maintain
You've got a bunch of inline SQL statements that do various queries that have no strong ties to the DB architecture. This can quite easily lead to queries that get "left behind" when the underlying DB structure changes, which, again, you will not see at build time.
Con It doesn't generate a class model or queries for you
Con It doesn't track objects and their changes so you can just call SubmitChanges()
