Um entendimento sobre os conceitos e tipos de bancos de dados NoSQL, abordar sobre o novo banco de dados NoSQL RavenDB, um banco de dados que além de ter sido escrito com .NET Framework, também é open source, e sua utilização em uma aplicação ASP.Net MVC.
Em que situação o tema é útil
Aprender os conceitos de bancos de dados NoSQL utilizando o RavenDB, aprender a utilizar o mesmo explanando seus recursos, e finalmente como utilizá-lo em conjunto com o ASP.NET MVC. No desenvolvimento de aplicações que seja importante utilizar um banco de dados NoSQL, principalmente em aplicações que apliquem o Domain Drive Design que é uma abordagem que utiliza fortemente os conceitos da orientação a objetos.
Resumo do DevMan
O mundo tecnológico atualmente tem passado por diversas mudanças, como, evoluções, conceitos antigos vêm sendo aplicado novamente, a maneira como se desenvolve aplicações, gerenciar e também como armazenar dados vem sofrendo alterações, e novos conceitos introduzidos. No gerenciamento surgiu o manifesto ágil, e em termos de desenvolvimento de sistemas, o mercado pouco a pouco tem entendido que sem boas práticas um software não sobrevive, e após muito tempo utilizando largamente bancos de dados relacionais, passa a se fortalecer o movimento por um armazenamento orientado a objetos.
O NoSQL tem vários entusiastas no país, e sua utilização vem crescendo muito. Além disto, o movimento NoSQL conta com excelentes opções de bancos de dados, dentre os quais está incluso o RavenDB, criado por Ayende Rahien, um dos desenvolvedores do já consagrado ORM NHibernate. A ideia é bem bacana e atende alguns cenários em que faz mais sentido um banco de dados não relacional. O objetivo de utilizar bancos de dados não relacionais vem amadurecendo pelo fato dos mesmos não atenderem a determinados cenários, e pela necessidade cada vez maior de reduzir custos relacionados a armazenamento de dados, haja vista que pode ser extremamente caro e complexo, dependendo da quantidade de volume de dados com o qual o sistema trabalha. Além de outros fatores que podem pesar em determinados cenários utilizar um banco de dados relacional. Um sistema não é feito somente de armazenamento, temos também o front-end, a camada de domínio e os testes. O ASP.NET MVC vem crescendo muito nos últimos tempos, principalmente por ser extremamente aderente as boas práticas e abordagens como TDD e DDD que vem tendo crescimento em seu uso cada vez mais. Juntando um banco de dados NoSQL que armazena objetos e uma aplicação concebida sob os fundamentos do DDD, TDD poderemos ter uma aplicação orientada a objetos de ponta-a-ponta e com uma manutenibilidade maior e mais aderente as mudanças.
Não é de hoje que o mercado percebe que muitas coisas precisam mudar. Tecnologias tornam-se ineficazes, dando lugar a outras tecnologias novas e mais poderosas, além do surgimento de novos padrões, algo comum neste tão dinâmico mundo de construção de sistemas. Atualmente vê-se na comunidade mundial um grande esforço em fazer com que as empresas (inclusive grande corporações) entendam que boas práticas são necessárias quando se quer construir um software consistente, de qualidade e que venha realmente atender as necessidades do usuário final. Padrões, princípios e boas práticas de desenvolvimento, vêm ganhando cada vez mais força neste cenário. Outro exemplo é relacionado à infraestrutura sistêmica e alta disponibilidade com o cloud computing que vêm trazendo uma nova filosofia de como escalar a infra e até hospedagem de uma aplicação, enfim, percebe-se que mudanças importantes estão acontecendo. E a forma que estes dados estão sendo armazenados? Os SGDB atuais suportam a abordagem atual de construção orientada a objetos? É, eles também não poderiam escapar desta avalanche de mudanças, mesmo com todo seu avanço nestes últimos 30 anos.
Test Driven Development (TDD) é uma técnica de desenvolvimento de software que se baseia em um ciclo curto de repetições: Primeiramente o desenvolvedor escreve um caso de teste automatizado que define uma melhoria desejada ou uma nova funcionalidade.
No DDD um modelo de domínio, são as classes que irão representar o negócio ao qual, a aplicação visa a atender. E não somente isto, elas não serão simplesmente um conjunto de classes, mas elas deverão expressar com exatidão o negócio, isto que dizer que até os termos utilizados pelos especialistas do negócio também serão refletidos pelas classes.
Relacional x Orientado a objetos
Dois paradigmas, duas abordagens diferentes, em cada uma delas existe uma particularidade. Devido a estes fatores, sempre houve a necessidade de se criar mecanismos para que os dois mundos se “falassem”. Surgiram então os famosos mapeadores objeto relacional, que permitem que suas aplicações fossem desenvolvidas orientadas a objetos, e os mesmos fossem armazenados em uma tabela através de um mapeador que realizava o “meio-campo” com um banco de dados relacional. Muito embora esta abordagem de desenvolvimento ainda seja bastante utilizada, até hoje em larga escala, há muitos problemas em se utilizar esta abordagem ou até mesmo utilizar um armazenamento relacional. Esta discussão é antiga e concentra-se justamente no esforço que é feito para fazer estes dois mundos se falarem sem problemas, sem que os “efeitos colaterais” aconteçam e tenhamos um sistema robusto e escalável. O esforço que é feito para “traduzir” um objeto, para uma tabela do banco de dados, acaba por tornar mais caro o processo de persistência das informações, o que inviabiliza a utilização desta abordagem em sistemas que trabalhem com volumes grande de dados. O tempo para consultar uma informação poderia ser extremamente maior, mesmo que os ORM´S modernos trabalhem com cache de dados. Por terem arquiteturas diferentes em certos cenários, torna-se melhor utilizar um banco de dados que entenda o “termo” objeto, que é o caso dos bancos de dados NoSQL.
...
