Design imutável com um ORM: Como as sessões são gerenciadas?

Question

Design imutável com um ORM: Como as sessões são gerenciadas?

#1 resposta do (1 votos)
#2 resposta do (0 votos)

5

Se eu fosse criar um site com um idioma mutável como o C # e usar o NHibernate, eu normalmente abordaria as sessões com a ideia de criá-las somente quando necessário e descartá-las no final da solicitação. Isso ajudou a manter uma sessão para várias transações de um usuário, mas impediu que ela permanecesse aberta por muito tempo, onde o estado poderia estar corrompido.

Em um sistema imutável, como o F #, eu acho que não deveria fazer isso porque supõe que uma única sessão poderia ser atualizada constantemente por qualquer número de inserções / atualizações / exclusões / ect ... Eu não sou contra a solução "using", já que eu pensaria que conectar o pool ajudará a reduzir o custo de conexão toda vez, mas não sei se todos os sistemas de banco de dados fazem o pool de conexão. Parece que deveria haver uma maneira melhor que não comprometa o objetivo da imutabilidade.

Devo apenas fazer um simples bloco de "uso" por transação ou existe um padrão melhor para isso?

database functional-programming orm

por Programmin Tool 11.01.2012 / 01:37

fonte

2 respostas

Tags database functional-programming orm

Como você decide os requisitos de disponibilidade do site? Chamadas Proxied não funcionam como esperado

score 1 · Answer 1

Eu meio que adivinho aqui, já que não estou familiarizado com o F #, mas parece que estamos falando de uma estrutura do tipo gerenciador de contexto semelhante à descrita neste artigo:

/// <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;
    }
}

Complete o artigo aqui:

link

No passado, usei uma ideia de "um contexto por solicitação" e adoro isso. O método "using" é muito pequeno para mim.

score 0 · Answer 2

Para agnóstico do idioma, o problema que você está falando é vincular uma conexão / transação a algum "contexto" e, em seguida, fazer uma comunicação muito detalhada e procedimental com a conexão e, em seguida, descartar / fechar / confirmar a conexão / transação e, finalmente removendo a conexão / transação do "contexto".

Pior na maioria das linguagens, esse "contexto" é mantido em um ThreadLocal, que é equivalente a uma variável global.

Meu palpite é que o F # provavelmente faz o que o C # faz, mas se você quiser fazer isso de uma maneira mais FP, eu olharia para implementá-lo como um Monad e ver como o Haskell gerencia o banco de dados.