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

[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

[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!