ORMs Meet SQL presentation for Tuga IT 2016

1. TUGA IT 2016
LISBON, PORTUGAL

2. THANK YOU TO OUR
SPONSORS

3. THANK YOU TO OUR
TEAM
ANDRÉ BATISTA ANDRÉ MELANCIA ANDRÉ VALA ANTÓNIO LOURENÇO BRUNO LOPES CLÁUDIO SILVA
NIKO NEUGEBAUER
RUI REISRICARDO CABRAL
NUNO CANCELO PAULO MATOS PEDRO SIMÕES
SANDRA MORGADO SANDRO PEREIRARUI BASTOS
NUNO ÁRIAS SILVA

4. ORMs Meet SQL
Ricardo Peres
@rjperes75

5. About Me
• Technical Evangelist at Simplifydigital (UK)
• Microsoft MVP, Visual Studio and Development Technologies
• Blogger
@rjperes75
rjperes@hotmail.com
http://weblogs.asp.net/ricardoperes

6. Agenda
• ORMs: The Good Parts
• The Problem
• How ORMs Try to Solve It
• Case Studies
• NHibernate and Entity Framework
• Micro ORMs
• Conclusion
• Food for Thought

7. ORMs: The Good Parts
ORMs are good at a number of things:
• Abstracting away databases and database-specific mechanisms (e.g., IDENTITY, sequences)
• Shielding us from database changes (e.g., using mappings)
• Ids are properly handled and propagated to children
• Avoiding writing tedious and repeating SQL (e.g., SQL is generated for us)
• Transactions and concurrency management is done for us
• Enforcing usage of good patterns (e.g., using parameters, no *)
• Embracing language-specific idioms and patterns (e.g., LINQ)
• Detecting changes for us (in entities and in model)
• Allow for complex scenarios that are not supported in relational databases (e.g., inheritance)
• Permit focusing on the language that developers are more proficient at (e.g., Java, C#) – enter
Domain Driven Design
• Fast to get things working (e.g., CRUDs, lists, binding)

8. The Problem (1 of 2)
It is generally accepted that ORMs make our lifes, as developers, easier,
but…
• SQL produced by ORMs is usually far from optimal / fast
This is usually because of the need for generic querying avoiding DB-specific
mechanisms
• Hiding complexity is not always a good thing
ORMs do somewhat complex stuff and make it seem simple
• Not meant to be used for everything
“If all you have is a hammer, everything looks like a nail”
ETL, reporting are two exemples of bad usage

9. The Problem (2 of 2)
It turns out that:
• SQL is still the most powerful way to perform queries in relational
databases
ORMs generally avoid advanced SQL
• Abstraction loses database-specific features
Lowest common denominator
• Generated schemas still require intervention / maintenance
DBAs are still required to tune the generated schemas, enforce conventions,
generate indexes, etc

10. How ORMs Try to Solve It (1 of 5)
• Two workflows:
• Database first – ORMs can adapt to what is already there
• Code first – It is possible to influence or bypass ORM functionality
• Some ORM features may come handy:
• Custom SQL
• Schema hints
• Lazy and eager loading
• Batching
• Cache
• Optimistic concurrency

11. How ORMs Try to Solve It (2 of 5)
Custom SQL
• It is possible to load, save,
update and delete entities from
user-supplied SQL, even stored
procedures
Index creation hints
• Besides primary keys, it is
possible to tell ORMs to
generate indexes for certain
columns

12. How ORMs Try to Solve It (3 of 5)
Lazy loading and lazy properties
• References (one-to-one, many-
to-one, one-to-many, many-to-
many) are only loaded when and
if necessary
• Even simple properties can be
loaded on demand (e.g., CLOB,
BLOB)
Eager loading
• It is possible to request that
entity references be loaded
together with the main entity

13. How ORMs Try to Solve It (4 of 5)
Batching queries
• ORMs can send together several
queries at once (both CUDs and
queries)
Batch loading
• When one loads a collection in a
loaded entity, up to N collections
in other loaded entities are
loaded too

14. How ORMs Try to Solve It (5 of 5)
Cache
• First and second level caches
means that we don’t even have
to go to the database
Optimistic concurrency
• Either a specific column or a set
of columns can be used for
detecting changes transparently

15. Case Study: NHibernate and Entity
Framework
NHibernate
• Mature and proven
• Lots of features
• Many supported databases
• Steeper learning curve
• No documentation
• Poor community support
Entity Framework
• Good integration with MS prods
• Is getting better on every version
• Good documentation
• Unstable
• Less features
• Only works well with SQL Server

16. Case Study: NHibernate and Entity
Framework
Feature NHibernate Entity Framework
Index creation hints X X
Lazy loading X X
Eager loading X X
Lazy properties X
Custom SQL X X
Batching CUDs X X
Batching queries X
Batch loading X
Cache X X
Optimistic concurrency X X

17. Case Study: Micro ORMs
• Micro ORMs do not attempt to be feature-rich
• Simple, sometimes it’s a single code file
• Fast
• No advanced features
• You still have to write your own SQL - no native querying (e.g., LINQ)
• Stuck to conventions for mapping

18. Conclusion
• ORMs are good to have at hand, but may not always be the best
solution
• Know your requirements
• Explore your ORM and get to know its full potential
• Use the best tool for the job at hand
• Understand what is going on underneath
• DBAs are not your enemies – learn from them!
• Learn SQL

19. Food for Thought
• Ten advantages of an ORM
• The Vietnam of Computer Science
• When Should I Use An ORM?
• Why debate politics when you can just blog about ORMs?
• What ORMs have taught me: just learn SQL
• Reply to "What ORMs have taught me: just learn SQL“
• ORM is an anti-pattern
• ORM Is an Offensive Anti-Pattern
• ORM Haters Don’t Get It

20. Q & A
?

21. Thank You!
Let me hear from you!

22. THANK YOU TO OUR
SPONSORS