[VB.NET] - Miglior modo di usare gli Entity Frameworks con MySQL

[Veronica80]

Ciao a tutti,
è ormai da tempo che per interfacciare i miei database con VB.NET uso EF.

Sono solita usare questo protocollo:

• Creo un oggetto globale del mio modello EF in un modulo
• Uso questo oggetto in tutto il progetto senza doverne mai ricreare un altro per lanciare i miei filtri sulle varie entità ecc (ndr: uso lambda per filtrare)

Mi è venuto il dubbio che però così facendo possa essere tutto meno performante piuttosto che creare ogni volta l'oggetto al bisogno per questioni di utilizzo di memoria volatile.

C'è un modo migliore tra i 2 o è uguale?
Grazie

[ciro78]

Ciao,
in genere è consigliabile avere le connessioni definito a livello globale attraverso un pool. Al momento poi si utilizzano. Creare ogni volta la sessione con il db potrebbe peggiorare le performance.

[alka]

Sono solita usare questo protocollo [...]

Cosa intendi con "oggetto globale del modello EF"?
Ti riferisci al DbContext o a qualcos'altro?

[Veronica80]

Cosa intendi con "oggetto globale del modello EF"?
Ti riferisci al DbContext o a qualcos'altro?

si si l'oggetto del dbContext

[Veronica80]

Ciao,
in genere è consigliabile avere le connessioni definito a livello globale attraverso un pool. Al momento poi si utilizzano. Creare ogni volta la sessione con il db potrebbe peggiorare le performance.

Grazie!!!

[alka]

si si l'oggetto del dbContext

A mio avviso, non è corretto: dietro le quinte dovrebbe essere trattato esattamente come la connessione al DB.

Il nome scelto non è casuale: Context.

Infatti, dovrebbe implementare il pattern cosiddetto Unit Of Work, ovvero essere creato per racchiudere le operazioni che afferiscono al caricamento, modifica, eliminazione di entità, che possono poi essere confermate in toto tramite SaveChanges() oppure annullate allo stesso modo scartando l'oggetto (ovvero uscendo dal metodo che lo utilizza, senza salvare nulla).

Non mi risulta peraltro che quell'oggetto sia thread-safe, quindi crearlo in modalità Singleton e utilizzarlo ovunque, la stessa istanza, è pure "pericoloso".

Un approfondimento generale si può trovare in questo articolo, molto dettagliato.

L'uso "migliore" o "corretto" prescinde dal database che sta dietro: le regole valgono per SQL Server, Firebird, MySQL, ecc.

Ciao!

[Veronica80]

A mio avviso, non è corretto: dietro le quinte dovrebbe essere trattato esattamente come la connessione al DB.

Il nome scelto non è casuale: Context.

Infatti, dovrebbe implementare il pattern cosiddetto Unit Of Work, ovvero essere creato per racchiudere le operazioni che afferiscono al caricamento, modifica, eliminazione di entità, che possono poi essere confermate in toto tramite SaveChanges() oppure annullate allo stesso modo scartando l'oggetto (ovvero uscendo dal metodo che lo utilizza, senza salvare nulla).

Non mi risulta peraltro che quell'oggetto sia thread-safe, quindi crearlo in modalità Singleton e utilizzarlo ovunque, la stessa istanza, è pure "pericoloso".

Un approfondimento generale si può trovare in questo articolo, molto dettagliato.

L'uso "migliore" o "corretto" prescinde dal database che sta dietro: le regole valgono per SQL Server, Firebird, MySQL, ecc.

Ciao!

Grazie Alka! Sembra abbastanza chiaro!
Allora direi che il metodo migliore è proprio creare il tutto al bisogno e poi dare un bel colpo di "dispose" a tutto!

[ciro78]

A mio avviso, non è corretto: dietro le quinte dovrebbe essere trattato esattamente come la connessione al DB.

Il nome scelto non è casuale: Context.

Infatti, dovrebbe implementare il pattern cosiddetto Unit Of Work, ovvero essere creato per racchiudere le operazioni che afferiscono al caricamento, modifica, eliminazione di entità, che possono poi essere confermate in toto tramite SaveChanges() oppure annullate allo stesso modo scartando l'oggetto (ovvero uscendo dal metodo che lo utilizza, senza salvare nulla).

Non mi risulta peraltro che quell'oggetto sia thread-safe, quindi crearlo in modalità Singleton e utilizzarlo ovunque, la stessa istanza, è pure "pericoloso".

Un approfondimento generale si può trovare in questo articolo, molto dettagliato.

L'uso "migliore" o "corretto" prescinde dal database che sta dietro: le regole valgono per SQL Server, Firebird, MySQL, ecc.

Ciao!

Sinceramente lo vedo limitante come sistema. Nel senso che sia con PHP che con JAVA, l'oggetto DB è comune. La famosa Unit of works è riferita alla singola transazione. A fronte di un pool di connessione ogni request ne utilizza una. Questo dovrebbe essere il senso dell ORM anche per evitare i tempi di handshake col DB.

[alka]

Sinceramente lo vedo limitante come sistema. Nel senso che sia con PHP che con JAVA, l'oggetto DB è comune.

Non mi è chiaro cosa intendi. Sia in PHP che in Java esistono classi per creare connessioni al DB: in entrambi i contesti andrebbero creati quando è necessario eseguire operazioni, aprendo contestualmente una connessione al DB, la quale andrebbe chiusa il prima possibile una volta che l'operazione è terminata. Le connessioni sono risorse limitate, e quindi è consigliabile a oggi tenerle aperte il meno possibile.

La famosa Unit of works è riferita alla singola transazione.

Esattamente. L'oggetto DbContext di EF raccoglie operazioni che vengono eseguite nel contesto di una transazione: quando hai terminato le operazioni, devi scegliere se confermarle o annullarle. La conferma avviene chiamando SaveChanges(), mentre l'annullamento viene implementato "dimenticando" le operazioni, ovvero lasciando "morire" l'oggetto DbContext, forzandone però la finalizzazione, ossia la chiusura della connessione. In caso contrario, le operazioni successive memorizzate nel contesto si andrebbero a sommare a quelle precedenti non ancora confermate, causando problematiche di vario tipo.

La connessione al DB è come l'apertura di un file: solo quando serve, si apre, e appena non serve più, bisogna fare in modo di chiuderla il prima possibile.

A fronte di un pool di connessione ogni request ne utilizza una.

I pool di connessioni sono gestiti dai driver, dai client o direttamente dal server: tu devi solamente richiedere l'apertura di una connessione, e se il server è stato configurato con un pool, te ne verrà assegnata una già pronta e presa dal pool stesso, in caso contrario verrà creata.

Il pool non deve essere gestito dallo sviluppatore, e lo sviluppatore non deve pensare di tenere una connessione aperta al DB più del dovuto.

Questo dovrebbe essere il senso dell ORM anche per evitare i tempi di handshake col DB.

No, il senso di un ORM è quello di mappare l'accesso al database su classi di un modello, usando diversi pattern (es. Active Record o affini), affinché l'uso delle classi generate in automatico o codificate in base alla struttura del DB "mascherino" l'esecuzione di operazioni sulle tabelle, sulle viste, ecc. In breve, lo scopo ultimo dell'ORM è mappare il DB su classi per velocizzare l'implementazione di un "data layer".

Detto questo, gli handshake col DB così come tutte le altre questioni sono demandate al driver, e tutto ciò che a livello di ORM si traduce nell'apertura di una connessione al DB, come nel caso del DbContext, va gestita tenendo conto di quanto detto prima riguardo la connessione come risorsa. Sarà cura del driver DB, della libreria client o del server "agganciare" una connessione nuova o presa da un pool.

Ciao!

[ciro78]

Ma infatti mi hai frainteso e io mi sono espresso troppo sinteticamente.

Anzitutto la mia versione dell ORM era semplificata e riferita alla gestione delle connessioni. Ovvio che serve per mappare il DB etc etc. É noto anche che il driver gestisce il pool ma appunto sono connessioni aperte a monte e disponibili a tutti. Sarà poi lo stesso driver a chiudere la connessione una volta fatto il commit.

Quello che volevo far emergere è che, considerando i sistemi attuali, tecnicamente si tende ad avere un qualcosa di centralizzato che gestisce le connessioni e le rende disponibili o le chiude su richiesta (commit o timeout).

Sicuramente è vero che avere un pool di connessioni occupa risorse ma oggi giorno è preferibile, per un discorso di performance sui tempi, averle a disposizione per eliminare appunto la latenza dovuta alla connessione.

Su un progetto a cui ho lavortato, ci veniva richiesto che la chiamata E2E fosse intorno agli 1.5s. É facile intuire come, fare rientrare in questo tempo anche l'apertura delle connessioni possa avere impatti importanti.