Pokud je to špatné používat inline SQL, jak se pomocí LINQ provádět dotazy se liší v praxi?

hlasů
13

Jaká je obecná shoda o použití LINQ provádět dotazy a manipulaci inline a jak se to liší se vkládání příkazů SQL do kódu (který je považován za ne ne)?

Položena 27/08/2009 v 03:20
zdroj uživatelem
V jiných jazycích...                            


9 odpovědí

hlasů
7

Ignoruje všechny používá související non-SQL z LINQ a právě s ohledem na LINQ-to-SQL.

LINQ dotazy jsou objekty, které si zachovávají dotazu definici a ekvivalentní SQL je instanci pouze v okamžiku dotazu je vlastně opakována. Který umožňuje komponenty musí být řádně odděleny a umožňují zpracování ve stylu potrubí , kde jsou dotazy vrácené spodních vrstev (např. Podle údajů) a transformovány vyššími složkami v zásobníku. Dotaz může přizpůsobit nové filtry, se připojí a další ‚artefakty‘ z každé složky ve zpracovatelském potrubí, dokud nedosáhne konečného formulář, který je případně opakována. Tato manipulace je prakticky nemožné pomocí rovné textu SQL.

Další výhodou je, že LINQ jeho syntaxe je snazší pochopit vývojářům non-databáze. SQL syntax odbornost je překvapivě těžké najít aktivum. Několik vývojáři jsou ochotni trávit čas učení jemnější body SQL mimo SELECT * FROM ... WHERE .... Syntaxe LINQ je blíže ke každodenním prostředí .NET a využívá stávající dovednost nastavit v této vrstvě (např. Výrazy lambda) v protikladu k vynucení vývojář naučit správné SQL pro cílené zadní konce (T-SQL, PL-SQL atd). Vzhledem k tomu, že výraz LINQ vyjadřuje požadovaný výsledek do značné míry přímo do relační algebře, poskytovatelé mají mnohem snazší práci do generuje odpovídající SQL (nebo dokonce vytvářet přímou plán provádění!). Srovnejte to s nemožný úkol ‚generické‘ databázové řidiči museli čelit vzácně s textem SQL. Pamatovat ODBC syntaxe escape, někdo?

Odpovězeno 27/08/2009 v 03:32
zdroj uživatelem

hlasů
5

Máte pravdu: „prohlášení Vkládání SQL v kódu není k zahození.“ Je to hrozné.

Přitom činí aplikace velmi spojený, křehké a náročné na údržbu. Alespoň, pokud to všechno mají procs, když změníte něco, co můžete udělat vyhledávání na závislostmi.

uložené procs, cítím se opravdu musím jít pryč taky pro ty procs, které jsou manipulaci obchodní logiky.

Důvodem je skutečnost, že obchodní logiky patří do podnikatelské vrstvy - ne datové vrstvy.

Samozřejmě, pokud je generován Linq to SQL dopadá něco chaotický a pomalé, musíš použít proc.

Jednou z velkých výhod LINQ to SQL je, že můžete řetězce dohromady filtry - jste kde klauzule se připočítá dynamicky prostřednictvím vašeho logiky, jak je požadováno. Nemusíte vytvářet nové procs jen proto, že chcete volat pro sadu dat na základě více params.

Odpovězeno 27/08/2009 v 04:01
zdroj uživatelem

hlasů
1

Dvě výhody „LINQ to SQL“ v porovnání s (společná nejhorší případ) „inline SQL“ .

Parametry jsou považovány za parametry, a to nejen jako dlouhých text - to překonává problémy SQL injection.

V rámci modelu odděleného vrstva umožňuje kompilaci kontroly, aby generované sql bude odpovídat schématu. (V nejhorším případě inline SQL, měli byste mít žádný způsob, jak vědět v době kompilace, pokud jste byli odkazování na sloupec, který byl smazán, například)

Odpovězeno 27/08/2009 v 03:27
zdroj uživatelem

hlasů
1

Vkládání příkazu SQL v kódu není k zahození. To vše závisí na tom, vrstva vaší aplikaci, kterou je psaní.

Cokoliv, co se týká čtení a zápis do úložiště dat, by měly být na vrstvě Data Access.

Odpovězeno 27/08/2009 v 03:25
zdroj uživatelem

hlasů
0

Pracoval značně s vloženými SQL je reálné nebezpečí, že se jedná o technologie pro generování kódu. Píšete kód v C (nebo jak se jazyk) a pak přejít na SQL, a pak zpět do C znovu. Později před kompilace s prepocessor přepíše kód, aby byl celý C. Výsledky mohou generovat velmi matoucí chybové zprávy. Jste nuceni naučit API pro interakci s databází, který vložené SQL se měl vás zbaví. A konečně, riskujete o vkládání obchodních pravidel do vašich dotazů matoucí obchodní vrstvu a datovou vrstvu. Linq vyhýbá některé z těchto problému. Za prvé, LINQ je součástí jazyka. Konstrukty pracovat více nebo méně jako programátor očekává. Tam je nějaký typ SQL syntax účastní, ale většinou syntaxe je zaměřena na jazyk hostitelské země (tj C #). Kontroly kompilace se provádí na skutečném kódu jste napsal. Pro ně není nutné překládat chyby do syntaxe před předzpracování. Výsledky dotazu jsou objekty a sbírky, stejně jako byste očekávali. Stále existuje nebezpečí smíchání obchodní logiku do datové vrstvy nicméně. Navíc Linq má své vlastní problémy s chybových zpráv, kde je pole v pochybnost je často nejsou zahrnuty. Stále se jedná o dobrý kompromis mezi objektem světem a relační světě.

Odpovězeno 17/08/2010 v 14:26
zdroj uživatelem

hlasů
0

V určitém řádku kódu, někdo, někdy se rozhodne, zda je vhodné psát SQL. Ale místo toho, dělat to, budete používat LINQ.

Takže to není otázka, jestli LINQ třeba inline při SQL neměli. Otázkou je, kde chcete, aby vaše připojení k reprezentaci ukládání dat být. Píšete-li LINQ v určité řádek kódu, a nemáte pocit, velmi příjemný a útulný tohoto rozsahu má přístup k uloženým datům, pak je to špatné místo.

LINQ je jen abstrakce pro manipulaci s daty. Je to zkratka pro filtrování sady. Stejně jako databáze pochopit SQL, .NET prostředí má jazyk, který bude mluvit s daty.

Jaký je rozdíl mezi LINQ a dělá if uvnitř smyčky, z údajů, které přišly ze souboru nebo síťový socket? Žádné, je to jen syntaxe. Máte-li SELECT * FROM table, filtrování každý řádek proti závislosti, jaký je rozdíl v tom where c.SomeProperty < xs LINQ? Jen syntax.

Jistě, LINQ zná a dělat víc, než jen vrací řádky z databáze. To vám umožní vytvořit instanci objekty ze sbírky, ale stejně tak = new ClassName(column1, colum2)z výsledků příkaz SQL.

Stručně řečeno, pokud někde psát inline SQL v kódu je ne-ne, tak to by mělo být písemně LINQ.

Ale toto se mění projekt od projektu. Databáze především porozumět SQL, takže alespoň někam do svého kódu, knihovny nebo životní prostředí jsou inline SQLs.

Odpovězeno 27/08/2009 v 03:49
zdroj uživatelem

hlasů
0

Z mého malého porozumění, ať už používáte LINQ-to-SQL nebo jakékoliv jiné ORM nebo vlastní kód, který obtéká SQL volání, to je v podstatě dává vám abstrakci, kdy nemusíte se starat o SQL.

Také, pokud se nemýlím - LINQ pro SQL podporuje pouze SQL Server.
Myslím, že to umožňuje sestavit kritéria v SQL podobným způsobem za použití syntaxe LINQ.

Osobně, nevím, proč by někdo použít LINQ to SQL.
Může odborník mi pomohl pochopit, že je třeba na to?

Odpovězeno 27/08/2009 v 03:34
zdroj uživatelem

hlasů
0

Při pohledu na další odpovědi, možná jsem nepochopil otázku ... ale já mluvím o běžném LINQ na sbírkách v jazyce C #, ne LINQ-to-SQL:

Při vložení SQL příkazy v kódu (jako protiklad k tomu, aby jim proměnné či jinak parametrizaci SQL), budete dělat to mnohem obtížnější pro sebe, pokud chcete podpořit jinou databázi v budoucnu. Stejně stará a standardizovány jako SQL znamená, že stále existuje mnoho nekompatibility mezi dodavateli.

S LINQ, přenositelnost není problém - kód je napsán v jazyce C # a LINQ je C #.

Odpovězeno 27/08/2009 v 03:31
zdroj uživatelem

hlasů
0

Za prvé LINQ příkazy jsou parametrizovány - vložené dotazy nemusí být nutně tak. Za druhé, LINQ v podstatě vytváří ORM vrstvou - umožňuje databázové objekty, které mají být ošetřeny v podstatě jako objekty v kódu - poskytuje kompilaci kontroly. Dotazu inline na druhé straně je blob textu, který se nezlomí při kompilaci ...

Odpovězeno 27/08/2009 v 03:28
zdroj uživatelem

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more