|
První případ (SqlQuery) obchází EF a bude mít tedy stejnou výkonnost jako přímé volání např. přes ADO.NET SqlCommand. Druhý případ je volání přes EF, které sebou samozřejmě nese navíc režii na transformaci LINQ dotazu do SQL a transformaci výsledků dotazu na objekty (v tomto případě na int). Tuším, že se někde uvádělo, že je to přibližně 30%, ale u takto jednoduchého dotazu to bude klidně víc (obecně doba režie EF je nezávislá na době vlastního zpracování dotazu na SQL). Hádám ale, že oba časy v tomto případě nebudou jinak závratné. Obecný postup při používání EF je takový, že datovou vrstvu a logiku implementujete s využitím EF (tedy druhá varianta). A teprve později při testování (někdy třeba až v produkci), když toto konkrétní volání identifikujete jako výkoností bottleneck dané uživatelské funkce (protože se třeba volá v cyklu hodněkrát), přistoupíte k nějaké optimalizaci. Jestli bude výsledkem optimalizace konkrétně přepsání pouze tohoto jednoho dotazu na první variantu bude záviset na dané uživatelské funkci. Pokud výkoností problém neodhalíte testováním nemá cenu provádět pre-optimalizaci nepoužíváním EF, protože nejste schopen dopředu odhadnout, který dotaz bude problém dělat a jen by to zbytečně vedlo na méně čitelný a měně udržovatelný kód.
|