Pergunta

A ignorância de persistência é normalmente definida como a capacidade de persistir e recuperar objetos .NET padrão (ou POCOs, se você realmente insistir em dar-lhes um nome).E um definição aparentemente bem aceita de um objeto .NET padrão é:

"...aulas comuns onde você se concentra no problema de negócios em questão sem adicionar coisas por motivos relacionados à infraestrutura..."

No entanto, vejo pessoas descrevendo o NHibernate como um framework que permite a ignorância da persistência, e ainda assim é um framework que não pode funcionar em qualquer objeto .NET padrão, apenas objetos .NET padrão que atendem a requisitos específicos de design, por exemplo (fonte):

  • Todas as aulas deve tem um construtor padrão
  • Alguns recursos não funcionam a menos que as aulas não sejam lacradas e todos os membros sejam virtuais
  • A identidade do objeto não funciona corretamente, a menos que você abuse de Equals/GetHashCode

(Aparte:Antes que alguém fique chateado, não pretendo criticar o NHibernate aqui, é apenas um exemplo frequentemente citado de uma estrutura que supostamente permite a ignorância da persistência.Tenho certeza de que argumentos semelhantes poderiam ser aplicados a outros ORMs que afirmam o mesmo.)

Agora, embora a classe em si não tenha nenhum atributo específico da estrutura de persistência ou classes base, etc., para mim ela não é realmente "ignorante em persistência" porque deve seguir um conjunto de diretrizes de design para facilitar uso pela estrutura de persistência escolhida.Você deve projetar e implementar a classe tendo em mente os requisitos da estrutura de persistência;se você ignorar isso, a classe pode não funcionar com isso.

O que estou tendo problemas com a definição de "ignorância persistente"/"POCO" é que não vejo como, conceitualmente, isso seja realmente diferente de adicionar atributos como [Serializable] ou [DataContract] ou [XmlType] ou qualquer outra anotação específica da estrutura de persistência que facilitar a persistência e recuperação da entidade usando essa estrutura.

Então, o que exatamente é “ignorância persistente”?

Claramente, a definição dele como sendo capaz de persistir "classes comuns" é uma falácia porque as do NHibernate são apenas comuns na medida em que não fazem referência a classes específicas do framework, enquanto são extraordinárias na medida em que exigem escolhas de design incomuns, como construtores padrão e todos -membros virtuais e implementações Equals/GetHashCode em tipos mutáveis.

É, portanto, razoável dizer que a "ignorância sobre persistência" é verdadeira quando os objetos facilitam o uso de uma estrutura de persistência (seja no design e na estrutura ou pelo uso de anotações específicas da estrutura), mas não executam eles próprios nenhuma lógica de persistência?

Foi útil?

Solução

Eu alegaria que, como a maioria das coisas, é uma escala deslizante. Há coisas que fazemos que querem ter a propriedade de persistência. Em uma extremidade da escala está essa coisa com todas as entranhas, dependências e código que são construídos personalizados para persistir apenas essa coisa de sua maneira específica. No outro extremo da escala está algo que acontece magicamente, tudo sem fazermos muito mais do que adicionar um token ou definir uma propriedade em algum lugar que faz com que essa coisa 'apenas persista'. Para chegar ao lado mágico da escala, existem estruturas, diretrizes de design, convenções, etc., que ajudam a mágica a acontecer. Eu acho que você poderia argumentar que uma ferramenta poderia ser produzida com menos requisitos e restrições do que o Nibernate, mas perseguiu o mesmo objetivo; Essa ferramenta hipotética seria mais longe ao longo de nossa escala.

Não sei se gosto tanto do termo 'ignorância de persistência'; É realmente sobre um objeto ignorando a implementação, a loja de apoio, o cache, esse tipo de coisa - um objeto normalmente está ciente de que é ou não persistente ou não. Mas isso é apenas semântica.

Outras dicas

Não acredito que sua compreensão (ou definição) de "ingestão de persistência" esteja errada.

o real questão é a de Abstrações com vazamentos. Simplesmente, a tecnologia existente faz com que muito Difícil de implementar PI verdadeiro.

Concordo com Mikeb - "Persistância Ignorância" é uma escala deslizante, não uma propriedade verdadeira/falsa de um determinado ORM.

Minha definição de verdadeiro Pi 100% seria que você poderia persistir em qualquer classe POCO possível, por mais complicada e vinculada a outras classes, sem alterar a classe de forma alguma.

Adicionando campos de identificação, decorando com atributos, herdando aulas do ORM, tendo que projetar suas aulas para que elas mapeem bem para as tabelas subjacentes em um RDB - todos reduzem a "pontuação do PI" abaixo de 100%.

Dito isto, eu escolhi usar o Fluent Nibernate Automapping, porque parece ter a maior pontuação do PI de qualquer uma das opções do ORM que eu observei.

Eu concordaria com sua definição:

Portanto, é razoável dizer que a "ignorância da persistência" é verdadeira quando os objetos facilitam o uso de uma estrutura de persistência, mas não realizam nenhuma lógica de persistência?

O código (ao contrário dos atributos) em suas classes não possui recursos intrínsecos à persistência.Construtores padrão podem ser necessários para persistência, mas não possuem código que realmente faça persistência.A camada de persistência poderia ser alterada substancialmente, diferentes bancos de dados poderiam ser usados ​​e a lógica de negócios permaneceria inalterada.

Uma classe ignorante persistente, é uma classe que não está ligada a uma estrutura de persistência.

Ou seja, a classe não tem absolutamente nenhum conhecimento de que existe uma estrutura de persistência presente, ela não herda de uma classe definida por essa estrutura nem implementa uma interface necessária para essa estrutura de persistência para funcionar.

Embora possa haver certas restrições menores que qualquer estrutura de ignorância de persistência exige, a incorporação de persistência permanece no local.

Embora uma classe no seu modelo de domínio (persistiu transparentemente com o Nibernate) deva ter um construtor de não-argumentos para que possa ser construído "dinamicamente", não é necessário ter uma certa classe base ditada pela estrutura nem é necessário ou substituir certos métodos especificados pela estrutura.

Na minha opinião, "a ignorância de persistência" é uma propriedade do seu modelo (modelo de domínio, modelo de negócios ou o que você possa se referir a ele). O modelo é de persistência ignorante porque recupera instâncias das entidades que contém através de abstrações (às vezes chamadas de repositórios). Essas abstrações posso Esteja implementado usando um ORM diretamente, mas, ao indicar, isso às vezes pode adicionar requisitos aos objetos que não pertencem naturalmente ao seu modelo. Portanto, eu não diria que um modelo que segue alguns requisitos de um ORM específico é 100% de persistência ignorante.

Você pode implementar a ignorância de Persisrtência usando uma classe para o domínio ou seu aplicativo e uma classe poco na persistência, quando você vai persistir o domínio que o mapeará em sua classe de persistência e usar o objeto de persistência para armazenar com Nibernate O Outro Framework

Sua classe de domínio deve ignorar como é persistido as informações, portanto, você não deve incluir regras de uma estrutura de persistência como (construtor vazio, propriedades virtuais etc.)

Essas regras da estrutura de persistência podem estar em sua classe de persistência.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top