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

@rjperes75rjperes@hotmail.comhttp://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