Date post: | 13-Jan-2017 |
Category: |
Software |
Upload: | ricardo-peres |
View: | 98 times |
Download: | 0 times |
TUGA IT 2016LISBON, PORTUGAL
THANK YOU TO OUR SPONSORS
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
ORMs Meet SQLRicardo Peres@rjperes75
About Me• Technical Evangelist at Simplifydigital (UK)• Microsoft MVP, Visual Studio and Development Technologies• Blogger
@[email protected]://weblogs.asp.net/ricardoperes
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
ORMs: The Good PartsORMs 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)
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 thingORMs 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
The Problem (2 of 2)It turns out that:• SQL is still the most powerful way to perform queries in relational
databasesORMs generally avoid advanced SQL
• Abstraction loses database-specific featuresLowest common denominator
• Generated schemas still require intervention / maintenanceDBAs are still required to tune the generated schemas, enforce conventions,
generate indexes, etc
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
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
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
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
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
Case Study: NHibernate and Entity FrameworkNHibernate• 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
Case Study: NHibernate and Entity Framework
Feature NHibernate Entity Framework
Index creation hints X XLazy loading X XEager loading X X
Lazy properties X
Custom SQL X X
Batching CUDs X XBatching queries XBatch loading X
Cache X X
Optimistic concurrency X X
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
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
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
Q & A
?
Thank You!
Let me hear from you!
THANK YOU TO OUR SPONSORS