ORMs Meet SQL
Download as PPTX, PDF0 likes282 views
This document summarizes a presentation about object-relational mappers (ORMs). It discusses the benefits of ORMs, including abstracting away databases and SQL generation. However, it also notes that ORMs have limitations like producing suboptimal SQL and hiding complexity. It then examines how ORMs try to address these issues through features like custom SQL, hints, and loading options. Case studies of NHibernate and Entity Framework are provided. The presentation concludes that ORMs are useful but not always the best solution, and that developers should understand what happens underneath and learn SQL.
ORMs Meet SQL
- 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