Thursday, April 17, 2008 9:30 AM
mjurek
ADO.NET Entities: 4. část - Srovnání s LINQ to SQL
V předchozích třech dílech jsem se věnoval víceméně technickému popisu, dnes se pustím na horkou půdu subjektivních hodnocení. Nejsem první, kdo se na toto téma zamýšlí, asi nejznámnější srovnání je zde. "Oficiální" Microsoft srovnání pokud vím zatím není. Každopádně se tyto dvě technologie do značné míry překrývají.
Nejzásadnější rozdílná věc je počet mapovacích vrstev. Zatímco LINQ to SQL je víceméně typový wrapper nad databází vytvořený 1:1 oproti databázové struktuře, ADO.NET Entities (Entity Framework, EF) pracují s konceptuálním modelem zcela nezávislým na databázi, který se mapuje na tzv. storage model (který je 1:1 popisem databáze nebo její podmnožiny). Z tohoto koncepčního rozdílu vychází většina skutečných rozdílů mezi technologiemi. Proto je někdy LINQ to SQL představován jako technologie pro rychlý vývoj (RAD) vytvořením silně typové vrstvy nad databází, zatímco EF jsou představovány jako technologie pro vytváření dlouhodobě udržitelných aplikací (díky izolaci kódu od změn v databázi). Toto dělení je podle mne dosti umělé - pokud totiž zůstanu u základní funkčnosti ADO.NET Entities, může být vývoj stejně rychlý a stejně RAD jako u LINQ to SQL, takže zde žádnou výhodu pro LINQ to SQL nepozoruji.
Co umí LINQ to ADO.NET Entities navíc:
- Výrazně bohatší možnosti modelování - navíc podpora komplexních typů, mapování entity do více tabulek, více entity setů pro jednu entitu, dědičnost typu table per type (TPT), relace M:N bez nutnosti pomocné entity (více viz 3. část - Možnosti modelování)
- Nezávislost na databázi - EF je postavený na principu poskytovatelů pro daný typ databáze, zatímco LINQ to SQL je pevně svázán s MS SQL 2000+
Co umí LINQ to SQL navíc:
- Větší variabilta pro řešení konfliktů při ukládání - pro každé pole je možné kontrolu zapnout/vypnout/zapnout-jenom-při-změně. V EF poslední možnost chybí.
- O něco komfortnější vygenerovaný objektový model - např. OnValidate(), RemoveAll(), GetChangeSet() - vše jde ale snadno dopsat i do EF a možná se to ve finální verzi též objeví.
- Jsou k dispozici již teď - EF budou dokončeny až během léta
- LINQ to SQL umožňuje nastavit Delay Loading (tj. automatické dodatečné natažení) pro individuální pole (např. velký BLOB v tabulce). Řešení v EF je oddělit BLOB do separátní tabulky (což je ovšem z databázového hlediska doporučené řešení) a namapovat entitu asociací 1:1.
Odlišnosti (ve skutečnosti jenom jedna, o které vím):
- LINQ to SQL je daleko horlivější v automatickém natahování dat z databáze - nemusíte se opravdu o nic starat. EF je mnohem konzervativnější - natáhne se jenom to, na co se explicitně zeptáte. Pokud chcete přejít na asociaci, musíte explictně zavolat Load() anebo při výběru entit z úložiště použít Include(jmenoAsociace) pro automatické (a velmi efektivní) natažení. Nechci hodnotit co je lepší.
Abych to shrnul - když si vše sečtu, jednoznačně mi vychází EF jako bezpečná volba prakticky ve všech situacích. Pár výhod LINQ to SQL lze snadno obejít, zatímco výhody EF pro dobrou architekturu a udržitelnost aplikace jsou evidentní. Vývoj s EF navíc může být prakticky stejně snadný jako s LINQ to SQL. Dle mého subjektivního názoru se tedy LINQ to SQL jeví jako téměř mrtvě narozené dítě...
Dále vyšlo: