Salve,
>La mia domanda da “ignorante” è tuttavia la seguente: esisteste qualcosa che possa in un certo senso emulare un recordset ? Ad esempio un datarow potrebbe scrivere direttamente dentro la tabella fisica nel database ?
si, c'e', ed e' Ado.NET... il diretto successore di ADO "secco"... anche questo e' il cosidetto "bare metal", il modo piu' veloce di interagire con le basi dati, ed espone modelli quali il Dataset, il DataTable (quest'ultimo utilizzabile anche come binding source), e modelli di lettura quali il DataReader, che e' il cursore firehose piu' veloce esistente di estrazione dati dallo stream TDS esposto ad esempio da SQL Server, etc... MA sono modelli ad oggetti "old style", malgrado, come detto, siano effettivamente il modello piu' veloce di interazione con le basi dati, quello che poi gli ORM quali Entity Framework vanno poi ad utilizzare dietro alle quinte nascondendo poi tutto l'utilizzo di SqlCommands etc...
gli ORM, tendenzialmente, "nascondono" il codice SQL da scrivere per l'interazione con la base dati...
avendo un oggetto POCO sul quale interagire tipo
dim order as new Order()
order.Id = x
order.CutomerId = y
...
orders.Add(order)
dbOrders.SaveChanges()
risulta piu' "bello" per tutti noi sfaticati, senza poi dover pensare a scrivere ad esempio anche il codice SQL e/o le stored procedure utilizzate da un SqlCommand di insert/update/delete...
quello che fa un ORM e' la "medesima cosa", costruisce dinamicamente il codice SQL per l'interazone con il db, ad esempio (te lo scrivo in c# che faccio prima :D, ma lo leggi comunque bene)
using (AdventureWorks db = new AdventureWorks())
{
var persons = (from p in db.People
join e in db.EmailAddresses
on p.BusinessEntityID equals e.BusinessEntityID
where p.FirstName == "KEN"
select new {
ID = p.BusinessEntityID,
FirstName = p.FirstName,
MiddleName = p.MiddleName,
LastName = p.LastName,
EmailID = e.EmailAddress1
}).ToList();
foreach (var p in persons)
{
Console.WriteLine("{0} {1} {2} {3} {4}", p.ID, p.FirstName, p.MiddleName, p.LastName, p.EmailID);
}
}
che "nulla" nasconde nella sintassi LINQ la sintassi che avresti composto in SQL per avere in questo caso una proiezione estratta tra People e EmailAddresses esposta come "lista" che sarebbe stata in ADO la tua DataTable con selezione di proiezione
SELECT p.BusinessEntityID, p.FirstName, p.MiddleName, p.LastName, e.EmailAddress1
FROM People p
JOIN EmailAddresses e ON p.BusinessEntityID = e.BusinessEntityID
WHERE p.FirstName = "KEN"
ma con la sintassi di cui sopra, non devi passare dal datasource ADO/Ado.NET al tuo object model di interazione applicativa, ma hai gia' una LIST di oggetti POCO che tu poi utilizzi a tuo comodo...
questa lista ha il vantaggio di essere piu' "marshallable" mentre gli oggetti Ado.NET non lo sono, e' molto piu' leggera (ma non ha direttamente il tracking delle modifiche), ....
ma cosi' va il mondo...
cio' non toglie, pero', che alla fine della fiera, quando avrai dei colli di bottiglia nell'interazione con il db, non userai piu' "direttamente" il modo ORM di salvataggio
persons.SaveChanges()
ma probabilmente andrai a ripescare Ado.NET per l'esecuzione di SqlCommands "velocissimi" :D
non dico quindi che gli ORM non vadano bene, ma potrebbero richiedere anche una ritoccatina manuale
Pensa che StackOverflow utilizza una propria customizzazione, Dapper, per sveltire cio' che Entity Framework faceva troppo lentamente, cioe' proprio l'accesso ai db… ed e' profondamente avvicinata al bare metal di Ado.Net.
smetto qui perche' si entra in guerra di religione tra chi piace scrivere codice SQL e chi no :D
in ogni caso, tutti dobbiamo "crescere" :D
my $ 0.02 (come si diceva una volta :D)
salutoni romagnoli
--
Andrea