Linq - opinioni

[pietro09]

ok hai ragione.
L'sql complesso lo si può comporre da programma: si tratta di comporre una stringa. Qui invece bisogna cablare il codice. Io non ho mai visto linq dinamico.
Se esiste, naturalmente, ben felice.
Ciao.

[djciko]

Io non ho mai visto linq dinamico.

a quanto pare è un altro semi-framework, basato su espressioni Lambda.
https://dynamiclinq.codeplex.com/

troppa carne al fuoco

[djciko]

si qui si tratta di usare le classi e le proiezioni del namespace ed abituarcisi.

comunque ho fatto un DB di esempio, per usare Linq To SQL, ed ho aggiunto una tabella.

Ho poi generato il file di Mapping (MoviesDatabase.dbml) e da Esplora Database trascinato la tabella nell'area di progettazione del Mapping.

nel codice c# poi:

MoviesDatabaseDataContext DC = new MoviesDatabaseDataContext(); // classi Stub generate automaticamente dopo il mapping

var ris = from film in DC.FILMS select film; // "FILMS" è la tabella nel DB, "film" è la proiezione della tabella nell'applicazione

gv.DataSource = ris;
gv.DataBind();

e funziona. Devo provare la sua immediatezza, ma non mi convince. Sarà che siamo troppo "vecchia scuola" ?

[pietro09]

io ho provato a suo tempo entity framework. Bello, ma preferisco l'sql classico.

[djciko]

pure io

[pietro09]

Sto usando massicciamente invece il DataTable. Il DataSet non l'ho mai usato, ma il DataTable, anche con un milione di record, funziona alla grande.
Francesco Balena consigliava di non superare qualche centinaio di record. Io pagino un milione di record senza uccidere il server (ambiente intranet con pochi utenti, si intende)
Insomma, lavorando molto coi dati, ritengo più utile conoscere al meglio l'ambinte (nel mio caso oracle) e imparare a usare il suo linguaggio.

Comunque, Linq mi piace. In determinati contesti è ottimo.
ciao.

[U235]

Sto iniziando ad usarlo.

Cosa ne pensate ?
Linq to Xml e Linq to Objects li trovo smart..
Ma Linq to SQL che vantaggio ha ?
Se ho necessità di cambiare una query devo rieffettuare il deploy dell'applicazione ?

Ciao,
beh credo che sostanzialmente Linq nasca dall'esigenza di tipicizzare le query (che siano verso oggetti, o verso xml o verso sql), motivo per cui (salvo altri casi spinti da esigenze differenti) non ha molto senso effettuare le query tramite stringa, in quanto la stringa viene interpretata a runtime, quindi saltano le regole del "fortemente tipicizzato".
In sostanza Linq, tra le altre cose, rende più difficile l'errore a runtime. Ma questo non significa che non si può comporre una query a runtime con Linq, solo che va "ragionata" in maniera differente. Inoltre esiste anche la possibilità di utilizzare prodotti che rendono possibile utilizzare anche le stringhe per comporre la query, ma ovviamente in questo modo torniamo a "rischiare" a runtime.
Per quanto riguarda Linq to SQL, la query viene tradotta in sql con una certa ottimizzazione, e viene eseguita nel momento in cui è necessario. Ovviamente parlare di Linq To SQL senza citare gli ORM non ha molto senso... Per cui diciamo che utilizziamo Entity Framework, ma perchè preferirlo al vecchio dataset? Non credo esista una risposta oggettiva, sicuramente dipende dalla propria formazione, EF (Entity Framework) consente di fare quello che effettivamente fa il dataset, ma in maniera più rapida e automatica. Inoltre EF (in particolare con Code First) consente di proggettare e trattare il database come se fossero dei normalissimi oggetti (come un dataset), con il vantaggio di evitare di eseguire l'elaborazione in più fasi. Per intenderci: dividendo in "livelli", col dataset "carichi" e "salvi" i dati tramite adapters che sostanzialmente vengono pilotati tramite tramite query "scritte" su stringa, per cui abbiamo un "livello" in cui si gestisce la comunicazione con il db (appunto gli adapters), e una dove vengono "lavorati i dati" in memoria. Per lavorare i dati intendo tutte quelle operazioni che fai sulla copia in memoria, per cui ad esempio "cicli" (se non usi linq) per filtrare, oppure, se non sei masochista, query Linq sul dataset. Vien da se che creare query Linq e poi usare i dataadapter sono due passaggi distinti che noi dobbiamo fare a mano, ovvero creare la stringa per il DataAdpter e creare query Linq To Dataset per elaborare i dati in memoria. EF rende lo stesso risultato con un solo passaggio, ovvero utilizzi solo query Linq To SQL senza preoccuparti di pensare anche alle query del DataAdapter. In pratica è come se avessi un dataset sempre carico ed aggiornato quando serve, ma senza magie di codice personale. Tenendo sempre presente che con EF puoi sempre utilizzare stored e scrivere le query direttamente a mano (e su stringa o no) nel caso serva ottimizzare la risorsa secondo propri canoni.
Ragion per cui, prima di poter apprezzare davvero le potenzialità di Linq To SQL, sarebbe necessario apprezzarne i vantaggi che porta Linq To (altro), e dopo capire perchè è tanto comodo saltare il passaggio [elaborazione Linq]->[elaborazione db] a favore del solo passaggio Linq To SQL.
Ma ogni caso è a se, per cui dire che EF è meglio del classico modo di fare non sarebbe corretto.

[pietro09]

caspita, finalmente un parere interessante

[U235]

caspita, finalmente un parere interessante

Troppo buono... ti ringrazio

[pietro09]

Troppo buono... ti ringrazio

Il discorso fila, ma è alla fine solo l'utilizzo pratico che può permettere di scegliere una tecnica piuttosto che un'altra.
Per esempio, io preferisco trattare l'xml e una serie di tabelle oracle, con strumenti diversi: xpath per l'uno e il classico sql per il secondo.

Andiamo sul pratico: ho una tabella o vista oracle e voglio fare una ricerca o voglio impostare un filtro.
Tipicamente presento un popup con diversi campi. Il risultato è la composizione della condizione where di una istruzione sql.

Bene, si riesce a farlo questo con Linq? se si, un esempio?