Administrace komentářů

Myslím, že vůbec nezáleží na tom jestli C# nebo Java. Klíč k výkonosti vidím spíše v pojetí ORM knihovny. Co očekávám od ORM knihovny? Dotazy vrací objekty, které podporují lazy loading a vrácené objekty (pokud mají unikátní klíč) jsou zapisovatelné . Prakticky vypadá lazy loading takto:

Person.address

 select … from ADDRESS A where A.PERSON_ID = :PERSONID 

Person.name = "pepin";

update PERSONS P set NAME='pepin',… where P.ID =…

Pokud má tyto požadavky ORM knihovna splňovat, tak jsou dvě cesty jak takových požadavků dosáhnout:

1. Knihovna vrací proxy objekty. Příkladem jsou Hibernate/NHibernate, Entity Framework, … a 90% všech ostatních ORM.
2. Knihovna vrací potomky nějakého generického ORM objektu. Nad ní jsou přes dědičnost definovány property (getter/setter) pro přístup k datům. Typickými zástupci této skupiny jsou Cayenne, Ujorm, Enterprise Objects Framework, Active JDBC. Žádný .NET ORM tohoto druhu neznám.

Nyní se pokusím ukázat k jakým neblahým koncům vede přístup číslo 1. Metody (DAO) objektu (a ani jeho potomci) nemohou přímo přistupovat k vlastním datům(!). Kdyby metody udělaly, tak obejdou lazy loading hook implementovaný v proxy objektu. Veškerá business logika je pak vyšoupnuta do vyšších vrstev do kterých se data kopírují. Touto vlastností se zabije objektový přístup a cesta vede beznadějně k antipaternu anemického modelu. Programátoři si pro kopírování dat ulehčují práci a vznikají knihovny jako Automapper a jim podobné. Architektura je pak ukázkovým příkladem lasagne code a ke všemu se většinou nezadržitelně stává i kódem s Ravioli strukturou. Samotný kód business logiky pak tvoří pouze minoritní část, zbytek kódu je balast. Bezuzdné kopírování dat (deep copy) a vytváření objektů pak dává pěkně zabrat alokátoru paměti a garbage collectoru. Spotřeba paměti stoupá do závratných výšin a operations oddělení posiluje HW

Další negativa proxy přístupu jsou jen kyselou špičkou na proxy ledovci:

• typeof(vytvořený_DAO_objekt) vrací Proxy. Drobnost, která komplikuje zdánlivě jednoduché situace.
• Obtížná práce s detached objekty. Množství výsledků google dotazu na LazyInitializationException asi mluví za vše.

Abych nebyl úplně jednostranný, tak zkritizuji i druhou cestu.

• Nefunguje code first přístup. Třídy DAO jsou generovány z modelovacího nástroje, které obvykle nepodporují verzování s možnostmi tfs/svn/git. Diff souborů modelovacího nástroje je většinou nepoužitelný a merge změn v generovaných DAO objektech se pak skoro nedá udělat. Řešení existují, ale zatím elegance code first nedosahují.
• Protože nefunguje code first, tak nejdou dobře dělat inkrementální změny v databázi na bázi kódu. popis knihovny C# a knihoven Java.

Žádná z výtek k cestě 2, ale nemá vliv na výkonnost a udržovatelnost aplikace. To že se nedá jít cestou code first a jde se cestou model first, já osobně považuji spíše za plus, protože se snáze odchytí pokřivené datové modely. Například teď jsem narazil na jeden projekt s přístupem code first, kde místo vazeb 1:N vytvářeli vazby M:N (s vazební tabulkou), protože jejich (homemade) ORM nepodporovalo vazby 1:N. Přirozeně taková chyba má velmi negativní výkonostní dopad a absence podstatných integritních kontrol v databázi navíc vytváří prostor pro datové chyby, které následně i vznikají. Osobně považuji důslednou kontrolu datového modelu jako velmi účiný a jednoduchý způsob jak zabránit zásadním chybám při analýze a následném vývoji SW. Taková kontrola se u přístupu database first mnohem lépe dělá.

Ale zpět k dotazu C# vs. Java. To jestli se bude psát dotaz jen s pomocí konstrukcí Java 1.4 v Cayenne ( rok 2005 )

  SQLTemplate q = new SQLTemplate(Person.class, "select * from PERSON where name ='pepin'");
  // SelectQuery q = new SelectQuery(Person.class, ExpressionFactory.Equal(Person.nameProperty,"pepin")); // anti sql injection version
  List p = ctx.peformQuery(q);

nebo LINQ ( rok 2007 )

  var query = from p in person
            where (p.name = "pepin")
            select p;

  Person.stream().filter(s-> s.name="pepin");

považuji spíše za kosmetické než revoluční změny vedoucí ke zvýšení výkonu. Klíče k výkonné a udržovatelné aplikaci leží totiž úplně jinde.

Mimochodem, asi jste zaregistrovali, že příklad z Cayenne je nejstarší - circa z roku 2005. Příklad pro Enterprise Objects Framework by byl ještě o 10 let starší, tedy cca z roku 1996(!).