Inicialmente vou discutir sobre algumas tecnologias que estão consolidadas entre os desenvolvedores de software que utilizam .NET, o NHibernate e o db4o.
O db4o para quem não conhece é um banco de dados orientado a objetos que promete desenvolvimento fácil e rápido, visto que o desenvolvedor não precisará realizar os famosos mapeamentos objeto-relacional, nem criar tabelas em banco de dados relacionais, e pode focar diretamente no desenvolvimento dos objetos de negócios. Pode ser utilizado tanto para aplicações embarcadas quanto para sistemas de qualquer tamanho.
Sua abordagem é simplista, uma vez aberto o container de objetos o desenvolvedor poderá salvar e manipular objetos de qualquer tipo, desde que o objeto possua sua classe visível ao escopo do banco de dados. Lembrando que, nesse caso, o escopo do banco de dados se refere a todas as classes visíveis dentro biblioteca que abre o container, incluindo classes carregadas dinamicamente.
Quando utilizando o db4o, o desenvolvedor não se preocupa com a criação de tabelas, o banco de dados se "adapta" ao formato e definições de cada classe, seus relacionamentos, etc. Desenvolvedores que utilizam o db4o possuem sempre a mesma impressão: "Essa é melhor coisa do mundo!!", "Que negócio massa!!", "Doido d+++!!!!!!!"...
No entanto, nem tudo são flores. Mesmo com o db4o existem algumas complicações. A primeira decorre da transição de bancos de dados relacionais para um orientado a objetos. No "mundo relacional" cada entidade equivale a uma tabela, equivalente a uma classe no "mundo OO", e cada tupla dessa tabela ou registro equivale a instância dessa classe. Até aqui tudo bem, o problema são as famosas e necessárias chaves primárias, que no db4o não existem, ou melhor, não devem ser utilizadas da mesma forma que num banco relacional.
Cada objeto no contexto do db4o possui sua própria identificação única que é gerada pelo próprio container de objetos do banco, isso poder acarretar num problema de adaptação para o desenvolvedor, mas nada muito problemático.
O segundo problema, talvez seja "o grande problema". Cada objeto do db4o ao ser atualizado deve ser reconhecido dentro do contexto de um container, isto é, caso o usuário abra um container, obtenha um objeto e feche o container, o objeto é considerado um novo objeto, pois não será reconhecido por outro container aberto posteriormente e se armazenado será duplicado no banco de dados, isto requer um tratamento especial ao se trabalhar com objetos desconectados do container. Esse problema, apesar se ser contornável com algumas estratégias, pode ainda ser agravado quando o objeto mantém dependências de outros objetos, pois a manutenção das referências deve ser realizada manualmente pelo desenvolvedor, isto é, ao se fazer um update em cascata, ou o desenvolvedor atualiza o objeto da referência ou deve removê-lo e então adicionar o novo, para evitar as famosas duplicações e objetos fantasmas, aqueles que o desenvolvedor achou que teria sido substituído, mas continuam armazenados.
Fora esses trabalhos a API do db4o é excelente, assim como o seu desempenho, quem trabalhar com o mesmo ficará apaixonado pelo seu modo de uso, as várias maneiras de se fazer as queries, inclusive o suporte ao Linq, que pessoalmente achei que ficou bem interessante.
Agora falaremos rapidamente sobre o NHibernate, que tenta amortizar a transição de um banco de dados relacional e seu uso num contexto orientado a objetos.
O NHibernate sem dúvidas é uma ferramenta excelente, um pouco trabalhosa, pois o usuário deve manter um arquivo XML, que contém o mapeamento das propriedades e campos da classe para os campos de uma tabela ou view num banco de dados relacional.
Possui um mecanismo de configuração que permite ao desenvolvedor construir o software independente do banco de dados que utilizará. Permite que o bancos de dados sejam mapeados mesmo depois de existentes ou seja criado um novo esquema para a representação do modelo.
O mecanismo de query do NHibernate seja via Critérios ou HQL é muito poderoso. É possível realizar queries complexas que serão devidamente traduzidas para cada banco de dados especificamente. Existem também uma implementação que permite que o NHibernate seja utilizado com o Linq e tal biblioteca virá junto com a versão 2.0 do mesmo.
O grande problema do NHibernate são os famosos mapeamentos, pois durante o ciclo de vida de qualquer software alterações acontecem, e podem ocasionar em mudanças no modelo, o que acarretam em mudanças nas classes e nos mapeamentos. Manter esses dois últimos sincronizados talvez seja a tarefa mais penosa pra quem utiliza o NHibernate.
Apesar de utilizar um mecanismo de sessão, ele não sofre do mesmo mal do db4o quanto a duplicação de dados, afinal temos um banco relacional que tratará desse problema da forma que estamos acostumados.
Para demonstrar mais sobre as diferenças desses dois bancos, irei publicar nas próximas postagens uma espécie de prova de conceito, onde para resolver um mesmo problema utilizarei ambos os bancos, mostrando as diferenças de cada na prática.
O db4o para quem não conhece é um banco de dados orientado a objetos que promete desenvolvimento fácil e rápido, visto que o desenvolvedor não precisará realizar os famosos mapeamentos objeto-relacional, nem criar tabelas em banco de dados relacionais, e pode focar diretamente no desenvolvimento dos objetos de negócios. Pode ser utilizado tanto para aplicações embarcadas quanto para sistemas de qualquer tamanho.
Sua abordagem é simplista, uma vez aberto o container de objetos o desenvolvedor poderá salvar e manipular objetos de qualquer tipo, desde que o objeto possua sua classe visível ao escopo do banco de dados. Lembrando que, nesse caso, o escopo do banco de dados se refere a todas as classes visíveis dentro biblioteca que abre o container, incluindo classes carregadas dinamicamente.
Quando utilizando o db4o, o desenvolvedor não se preocupa com a criação de tabelas, o banco de dados se "adapta" ao formato e definições de cada classe, seus relacionamentos, etc. Desenvolvedores que utilizam o db4o possuem sempre a mesma impressão: "Essa é melhor coisa do mundo!!", "Que negócio massa!!", "Doido d+++!!!!!!!"...
No entanto, nem tudo são flores. Mesmo com o db4o existem algumas complicações. A primeira decorre da transição de bancos de dados relacionais para um orientado a objetos. No "mundo relacional" cada entidade equivale a uma tabela, equivalente a uma classe no "mundo OO", e cada tupla dessa tabela ou registro equivale a instância dessa classe. Até aqui tudo bem, o problema são as famosas e necessárias chaves primárias, que no db4o não existem, ou melhor, não devem ser utilizadas da mesma forma que num banco relacional.
Cada objeto no contexto do db4o possui sua própria identificação única que é gerada pelo próprio container de objetos do banco, isso poder acarretar num problema de adaptação para o desenvolvedor, mas nada muito problemático.
O segundo problema, talvez seja "o grande problema". Cada objeto do db4o ao ser atualizado deve ser reconhecido dentro do contexto de um container, isto é, caso o usuário abra um container, obtenha um objeto e feche o container, o objeto é considerado um novo objeto, pois não será reconhecido por outro container aberto posteriormente e se armazenado será duplicado no banco de dados, isto requer um tratamento especial ao se trabalhar com objetos desconectados do container. Esse problema, apesar se ser contornável com algumas estratégias, pode ainda ser agravado quando o objeto mantém dependências de outros objetos, pois a manutenção das referências deve ser realizada manualmente pelo desenvolvedor, isto é, ao se fazer um update em cascata, ou o desenvolvedor atualiza o objeto da referência ou deve removê-lo e então adicionar o novo, para evitar as famosas duplicações e objetos fantasmas, aqueles que o desenvolvedor achou que teria sido substituído, mas continuam armazenados.
Fora esses trabalhos a API do db4o é excelente, assim como o seu desempenho, quem trabalhar com o mesmo ficará apaixonado pelo seu modo de uso, as várias maneiras de se fazer as queries, inclusive o suporte ao Linq, que pessoalmente achei que ficou bem interessante.
Agora falaremos rapidamente sobre o NHibernate, que tenta amortizar a transição de um banco de dados relacional e seu uso num contexto orientado a objetos.
O NHibernate sem dúvidas é uma ferramenta excelente, um pouco trabalhosa, pois o usuário deve manter um arquivo XML, que contém o mapeamento das propriedades e campos da classe para os campos de uma tabela ou view num banco de dados relacional.
Possui um mecanismo de configuração que permite ao desenvolvedor construir o software independente do banco de dados que utilizará. Permite que o bancos de dados sejam mapeados mesmo depois de existentes ou seja criado um novo esquema para a representação do modelo.
O mecanismo de query do NHibernate seja via Critérios ou HQL é muito poderoso. É possível realizar queries complexas que serão devidamente traduzidas para cada banco de dados especificamente. Existem também uma implementação que permite que o NHibernate seja utilizado com o Linq e tal biblioteca virá junto com a versão 2.0 do mesmo.
O grande problema do NHibernate são os famosos mapeamentos, pois durante o ciclo de vida de qualquer software alterações acontecem, e podem ocasionar em mudanças no modelo, o que acarretam em mudanças nas classes e nos mapeamentos. Manter esses dois últimos sincronizados talvez seja a tarefa mais penosa pra quem utiliza o NHibernate.
Apesar de utilizar um mecanismo de sessão, ele não sofre do mesmo mal do db4o quanto a duplicação de dados, afinal temos um banco relacional que tratará desse problema da forma que estamos acostumados.
Para demonstrar mais sobre as diferenças desses dois bancos, irei publicar nas próximas postagens uma espécie de prova de conceito, onde para resolver um mesmo problema utilizarei ambos os bancos, mostrando as diferenças de cada na prática.
0 comentários:
Postar um comentário