Por que tantos programadores odeiam absolutamente as camadas de prevalência de objetos?

A prevalência é uma técnica simples para fornecer propriedades ACID a um modelo de objeto na memória com base na serialização binária e no log write-ahead. Funciona assim:

• Comece com um instantâneo. Serialize o modelo de objeto e grave-o em um arquivo.
• Crie um arquivo de diário. Para cada chamada no modelo de objeto, serialize a chamada e seus argumentos.
• Quando o diário fica grande demais, você está encerrando, ou é conveniente, execute um ponto de verificação: escreva um novo instantâneo e trunque o diário.
• Para reverter ou recuperar de uma pane ou choque elétrico, carregue o último instantâneo e reexecute todas as chamadas gravadas no diário.

As precauções necessárias para fazer este trabalho são:

• Não deixe escapar referências de objetos mutáveis ​​ou entre na camada de prevalência. Você precisa de algum tipo de esquema de proxy ou OID, como se estivesse fazendo RPC. (Este é um erro de novato tão comum que foi apelidado de ' problema do batismo '.)
• Toda a lógica alcançável de uma chamada deve ser completamente determinística e não deve executar chamadas de E / S ou de SO com lógica de negócios. Gravar em um log de diagnóstico provavelmente é bom, mas obter a hora do sistema ou iniciar um delegado assíncrono geralmente não é. Isso ocorre para que o diário seja repetido de forma idêntica, mesmo se for restaurado em uma máquina diferente ou em um horário diferente. (A maioria dos códigos de prevalência fornece uma chamada de tempo alternativa para obter o carimbo de data / hora da transação.)
• A simultaneidade do escritor introduz ambiguidade na interpretação do diário, portanto é proibida.

É porque ...

• as pessoas desenvolveram um gosto ruim para eles depois de tentar usar um em um projeto que não era adequado ^* a ele?
• A defesa estridente de Klaus Wuestefeld afastou as pessoas ?
• as pessoas que gostam do modelo de programação imperativa não gostam de separar a E / S do cálculo , preferindo intercalar a computação com as E / S e as chamadas de segmentação?
• as camadas de prevalência são tão conceitualmente simples e tão intimamente ligadas às características da estrutura em que habitam que geralmente são personalizadas para o projeto, o que as torna muito estranhas / fora do padrão / arriscadas?
• é muito difícil manter o que você precisa ter cuidado para não fazer?
• as cabeças dos novatos parecem explodir quando confrontadas com algo que não é o mesmo tipo de aplicativo orientado a banco de dados de duas camadas que aprenderam a escrever na escola? ;)

^* Os inteiros fits conjunto de dados na memória RAM , você não precisa escritor concorrência, e você não precisa fazer consultas ad-hoc, relatórios ou exportação para um data warehouse. Com desculpas ao SQLite, a prevalência é uma melhoria nos arquivos salvos, não um substituto para o Oracle.

Eu acho que um dos problemas é que eles têm um caso de uso MUITO específico (seu motivo não adequado). Eu construí e trabalhei em sistemas que usam essa abordagem e, quando você tem um problema que é realmente esse problema, pode ser uma solução maravilhosa.

Outra parte é que ele se parece muito com alguns dos mais dolorosos pedaços de armazenamento de dados personalizados que você costumava encontrar há mais de 10 anos e tem algumas das mesmas armadilhas (pense no btreive atualizado em lotes, por exemplo) que traz o seu ponto "muito personalizado", mas também dificulta a localização das peças que trabalham educadamente com ele.

A última parte é que eles podem ser difíceis de serem consultados em muitos casos e as pessoas em geral estão bastante acostumadas a poder obter suas respostas agora.

Eu acho que você primeiro precisa demonstrar que muitos desenvolvedores os odeiam. Eu não acho que é esse o caso. Considere que o passarinho, há um tempo atrás, formalizou um tipo de padrão para isso aqui .

A resposta para a pergunta é que, embora a teoria seja simples, a prática não é.

Apenas testar essa configuração requer dezenas de casos de teste, processo mutli ou código multiencadeado, e isso salta para centenas de condições possíveis que precisam ser testadas, tanto para persistência quanto para recuperação.

Qualquer monitor de transação, como CICS, Tuxedo, Weblogic, Websphere, JBOSS ou .NET, fornecerá todos esses recursos de maneira limpa e testada. E qualquer banco de dados fornecerá transacional / persistência "suficiente" para a maioria dos aplicativos.

É principalmente um caso dessa roda que foi inventada e aperfeiçoada há muito tempo.

Os pré-requisitos parecem um pouco onerosos para codificar, especialmente com a maioria dos sistemas que não precisam de conformidade com ACID ao executar na memória. A sobrecarga parece um pouco desagradável também - há muito rastreamento de estado envolvido lá.