Poslední reinkarnace LINQu, o které jsem se zmínil v přehledovém článku, je LINQ to ADO.NET Entities, o kterém jsem uvedl:

"LINQ to Entities - Entities je nový koncept v ADO.NET. Původně měly být součástí .NET frameworku 3.5, ale budou vydány až s novým SQL Serverem 2008 někdy v létě - i když budou pracovat i s jinými databázemi. Informací je zatím spíše méně než více, tak snad někdy v budoucnu o nich něco napíšu."

Nyní jsem měl trochu času podívat se na tuto technologii blíže. Na první pohled je prakticky nerozlišitelná od LINQ to SQL. Například objektový model a možnosti jsou prakticky totožné. Místo DataContext použijete ObjectContext a tak podobně. Kód není v tomto případě zase tak důležitý. V čem je tedy rozdíl?

Entity přinášejí novou abstrakční vrstvu mezi obchodní logiku a databázi. Entity zastupují něco konkrétního v projektu (zákazník). Poskytovatel entit (pro SQL Server nebo jinou databázi) pak poskytuje aplikaci tyto entity ve formě objektů anebo ve formě XML reprezentací. K tomu se používá buď Entity SQL, tj. speciální dialekt jazyka SQL pro dotazování do poskytovatele entit. Úkolem poskytovatele je poté přeložit příkazy Entity SQL do jazyka konkrétní databáze, vykonat příkaz a vrátit správnou reprezentaci entit. Abyste se vyhnuli Entity SQL, použijete pravděpodobně LINQ to Entities - stejně jako použijete LINQ to SQL, abyste se vyhnuli T-SQL jazyku pro přístup k datům. Je to velmi přirozené a komfortní a je to v zásadě zcela stejné jako u LINQ to SQL - jenom je tam jedna abstrakční vrstva navíc.

Pro entity je důležité modelování. Model je sice možné vygenerovat z databáze, ale není to zcela praktické. Lepší je "pořádný" model, ze kterého se pak buď vygeneruje databáze anebo se model namapuje na existující databázi. Model pak určuje XML podobu entit a zároveň se z něj snadno vygeneruje objektová reprezentace entit. Jednou z výhod entit je totiž snížení počtu objektů, které musí vývojář používat. Např. typický Zakaznik bude aspon ve 3 tabulkách - v jedné osobní data, ve druhé adresy, ve třetí telefony. Ve světě entit namodelujete prostě pouze entitu Zakaznik, která bude mít kolekci komplexního typu Adresa a kolekci komplexního typu Telefon. V okamžiku výběru dat stačí provést pouze jeden výběr a vše o zákazníkovi dostanete naráz (vs. tři výběry při přímém přístupu do databáze). A to nemluvím o uložení změn, kde je situace ještě komplikovanější - zde pouze pracujete s objekty a ADO.NET Entities se postarají o zbytek.

Samozřejmě pro "hobby" vývoj jsou entities zbytečná komplikace a je spíše na místě doporučit LINQ to SQL. Entities jsou spíše mířeny na profesionální vývoj. Entities trochu navozují asociaci na Entity Beans, které jsou v J2EE už asi tak 10 let (přesto je málokdo používá). ADO.NET Entities jsou v něčem podobné a v něčem jiné. Otázkou zůstává jejich režie - solidní výkonnostní test jsem zatím neviděl (mimochodem právě pověěsti o špatné škálovatelnosti zlomily vaz Entity Beans).

Důležité je, že ADO.NET Entities používají model poskytovatelů, takže budou k dispozici pro více databází. Microsoft pravděpodobně v první vlně spolu s uvedením SQL 2008 za cca 3/4 roku uvede pouze poskytovatele pro SQL server 2000 a vyšší, ostatní budou od třetích stran (určitě od Oracle a IBM). S entitami je tedy možné změnit výrobce databáze anebo dokonce jejich strukturu a nešáhnout při tom do kódu - změny se provedou pouze v mapovacím souboru. V SQL 2008 by zároveň měly být nějaké nové vlastnosti pro entity i na straně databáze (snad podpora Entity SQL a mapování na straně databáze?), ale dokumentace je zatím dost kusá (eufemismus pro "žádná").

Na závěr pár odkazů: