Design immutabile con un ORM: come vengono gestite le sessioni?

Question

Design immutabile con un ORM: come vengono gestite le sessioni?

#1 da (1 voti)
#2 da (0 voti)

5

Se dovessi creare un sito con un linguaggio mutevole come C # e utilizzare NHibernate, normalmente mi avvicinerei alle sessioni con l'idea di crearle come create solo quando necessario e disponili al momento della richiesta. Ciò ha aiutato a mantenere una sessione per più transazioni da parte di un utente, ma impedisce che rimanga aperta troppo a lungo dove lo stato potrebbe essere danneggiato.

In un sistema immutabile, come F #, penserei che non dovrei farlo perché suppone che una singola sessione possa essere aggiornata costantemente da un numero qualsiasi di inserimenti / aggiornamenti / cancella / ect ... Non sono contrario la soluzione di "utilizzo" dal momento che penserei che il pooling di connessione contribuirà a ridurre il costo della connessione ogni volta, ma non so se tutti i sistemi di database fanno il pooling delle connessioni. Sembra proprio che ci dovrebbe essere un modo migliore che non comprometta l'obiettivo di immutabilità.

Dovrei semplicemente fare un semplice "utilizzo" di un blocco per transazione o esiste un modello migliore per questo?

database functional-programming orm

posta Programmin Tool 11.01.2012 - 01:37

fonte

2 risposte

Leggi altre domande sui tag database functional-programming orm

Le chiamate in proxy non funzionano come previsto Quali sono i diversi modi per eseguire l'autorizzazione in un'applicazione Web diversa dall'autorizzazione basata sui ruoli?

score 1 · Answer 1

In questo caso, mi viene spontaneo pensare che non conosco assolutamente F #, ma sembra che stiamo parlando di una struttura di tipo context manager simile a quella delineata in questo articolo:

/// <summary>
/// Returns a shared ObjectContext instance.
/// </summary>
public NorthwindObjectContext ObjectContext
{
    get
    {
        string ocKey = "ocm_" + HttpContext.Current.GetHashCode().ToString("x");
        if (!HttpContext.Current.Items.Contains(ocKey))
            HttpContext.Current.Items.Add(ocKey, new NorthwindObjectContext());
        return HttpContext.Current.Items[ocKey] as NorthwindObjectContext;
    }
}

Completa l'articolo qui:

link

In passato ho usato un'idea di "un contesto per richiesta" e lo adoro ... il metodo "using" è troppo piccolo per me.

score 0 · Answer 2

Per essere indipendente dalla lingua, il problema di cui parli è vincolare una connessione / transazione ad un "contesto" e poi fare una comunicazione molto statica e procedurale alla connessione e quindi disporre / chiudere / impegnare la connessione / transazione e infine rimuovendo la connessione / transazione dal "contesto".

Peggio ancora nella maggior parte delle lingue questo "contesto" è mantenuto in un ThreadLocal che è in qualche modo equivalente a una variabile globale.

La mia ipotesi è F # probabilmente fa ciò che fa C # ma se volessi farlo in un modo più FP, considererei l'implementazione come Monade e vedrò come Haskell gestisce le cose del database.