NHDay Introduction to LINQ2NH

LINQ2NH
Ricci Gian Maria
Giorgetti Alessandro

Nhibernate permits you to query database with different techniques
NHibernate support for Query
HQL
ICRITERIA
SQL
NHIBERNATE

The LINQ query expressed by code gets translated into an “Expression Tree”
An Expression Tree is a representation of the query with a tree like this one
What is needed to build a LINQ provider
3 + (5 + 9) * 2

If an arithmetic expression is simple to visualize as a tree a LINQ query could be more complex.
Luckily enough, we do not need to know this to use LINQ2NH, but is useful to understand the process
Expression Tree in real world

We already have a LINQ2NH provider, is it not good?
We have LINQ2NH in 2.1.. So?
LINQ2NH
HQL
ICRITERIA
SQL
NHIBERNATE

2.1 LINQ provider is limited by features offered by ICriteria
The query gets translated from ExpressionTree to ICriteria then from ICriteria to the real query
ICriteria misses some features like Having clause
It is difficult to create complex query with ICriteria so it is difficult to support full LINQ syntax
Current situation

First of all there was a rewrite of the HQL parser using an AST (Abstract Syntax Tree) based on ANTLR
Steve Strong started from the Java ANTLR parser and converted for C#
The resulting HQL engine now has four steps, the hard work is between 2nd and 3rd steps
A new idea – use HQL

Why rewrite HQL parser is needed for LINQ
The big idea is to create a provider that translate an Expression Tree to the same Parse Tree of HQL
STRING(HQL)
LINQ
The complex part, is translating the Parse tree
Translation of parse tree is the point where mappings are consulted to generate the SQL tree
Reusing the same code for HQL and LINQ is the key for success and performance
PARSE TREE
ICRITERIA
SQL
NHIBERNATE

Is LINQ2NH mature enough?
Actually the provider supports many features, but since parsing an Expression Tree is not so simple we still have something unsupported
We will see this in detail in the second part, you should simple be aware that not full LINQ syntax is supported

Whylinq 2 NH
If we already have HQL, ICriteria and SQL, we really need LINQ?

LINQ is strongly typed, so you have full intellisense power and compile time checking
Refactoring capabilities, if you rename a property of a mapped class, you automatically have your LINQ queries updated
LINQ is standard in .NET, maybe you already know it, and you can use to query XML, object in memory, LDAP tree, Entity Framework  and so on.
Differencebetween HQL and LINQ

Deferred execution – a key concept of LINQ
Some of the LINQ operator are called: “deferred” operator
A deferred operator is evaluated only during the iteration of the content, or if you call a “not deferred” operator (like ToList() )

Deferred execution – even in LINQ2NH
The very same happens for LINQ2NH queries.
Nothing get executed here, you are only defining a query like you do with ICriteria
Since Count is a “non deferred” operator, a query to the database is issued.

LINQ query is an expression tree that can be manipulated by code
Like ICriteria is simple to add and remove condition, projections to an existing query.
You can pass a LINQ query between layers, each layer can manipulate the query in a very simple way.
Differencebetween HQL and LINQ

Very easy projection
You can have one layer that manage the where part and another one that use projection
You can project into Dto (Data Transfer Object) with great easy, respect HQL
You can leverage Anonymous Type instead of DTO.
Difference between HQL and LINQ

You can build on the fly complex anonymous DTO, with calculation in it and let the provider do the work
LINQ is expressive
Since you want to use the year part of the BirthDate property, the provider is using datepart SQL function
Provider is smart, and select only what is needed and not unnecessary properties

Linq to Nh – Part 2

A thing you need to be aware of…
Some things that actually ‘do not work’
How to extend the provider to overcome issues and add features.
Part 2 - Agenda

Nhibernate best practice: use explicit Transations!
Deferred execution might cause troubles when coupled with Transaction Management policies.
It’s very easy to execute code outside the scope of a transaction, and you will hardly spot it at first.
If your repository/dao or whateever data access strategy you have, exposes IQueriable<T> interfaces you need to be careful and call the functions that actually ‘trigger’ the Linq query evaluation inside the scope of your transation (i.e.: GetEnumerator(), Count(), ToList(), Single(), etc…).
A Thing to be Aware of…Linq2Nh and Transactions

Some Functions/Operators not supported – for example: Equals() is supported only for strings at the moment, for all other types you can use the ==operator.
Problems when using Ilists<T> while trying to create expressions that use ‘contains’ to realize ‘Select..from…where..in’ queries. The parser goes crazy and try to compare an IList<T> to T entities.
Custom IUserType(s) not supported yet. (It’s a bug and should be corrected soon..remember it’s an alpha version).
Problems with some Joins and Nested Queries, you need to rework your code if you want to use Linq to perform these kind of queries.
During everyday usage of the provider you can encounter the following problems:
Some things that actually ‘do not work’

Fix some of the holes in the provider – the missing equals for example.
Add new features and functionalities.
Extending the provider is very easy and it allows you to:
Extending Linq To NHibernate

Given your Linq Query a parser examines it.
Each segment of the expression that forms the query is translated from a Linq Expression to an Hql Expression (The old provider was based on the ICriteria API).
Your operators are replaced with the predefined corresponding ones (or the one you defined/customized).
The result is the internal representation of an HQL query that is later on converted to a real SQL query.
Putting it simple the new provider works this way:

Create a ‘Method Generator’ – a class that basically tells Nhibernate how to build an Hql Expression that represent your Linq function.
Register the Method Generator in the internal methods repository – inherit from DefaultLinqToHqlGeneratorsRegistry to add you custom methods.
Tell Nhibernate to use your custom method registry intead of the default one:
To customize the provider you have to:

Inherit from the base class BaseHqlGeneratorForMethod
Provide the list of supported methods (a sort of call signatures)
Override the BuildHql() function that will provide the HqlExpression that represent your operator/function
Implement the IRuntimeMethodHqlGeneratorinterface (usefull when you do not know the types involved ‘at design time’).
you do not provide a list of function calls to match
Implement the bool SupportsMethod(MethodInfo method) – states if the method can be represented by the generator.
Implement the IHqlGeneratorForMethod GetMethodGenerator(MethodInfo method) – returns a method generator that will be used to generate the HqlExpression
To create a Method Generator you can:

Demo
Extending the provider

Thank you for attending!

NHDay Introduction to LINQ2NH

by Gian Maria Ricci on Oct 11, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 555

Statistics

NHDay Introduction to LINQ2NH — Presentation Transcript

http://dimotnet.wordpress.com	553
http://translate.googleusercontent.com	2