O injustiçado DataSet

Desde sempre eu ouvia falar mal dos DataSets, obviamente quem mais criticava vinha do Java, mas também escuto muitos desenvolvedores .NET falando mal de arquiteturas que usam DataSets e TableAdapters.

Uma das frases que li e me motivaram a escrever esse post está no blog do Fábio Galuppo, um cara do qual eu tenho muito respeito, a frase é a seguinte: "... a melhor fonte para dados serem mapeados são objetos, não Datasets!".

O fato é que eu não creio que as coisas funcionem bem assim. Tudo depende. A panacéia da orientação a objetos trouxe à tona o Object-Relation Mapping (ORM). Ou seja, a OOP trouxe muitas "solução" para problemas antigos, mas trouxe também novos problemas. Bem, nada contra esquecer as Querys e trabalhar apenas com Objetos, e mais ainda, abstrair a camada de dados, mas infelizmente eu não conheço hj uma ferramente boa que consiga unir a "forma direta e fácil" das querys se relacionarem com os dados e o poder da Orientação à Objetos.

Em projetos grandes até justifica-se a adoção de uma framework de persistência, ou a construção de uma. Mas nem sempre temos recursos para investir numa arquitetura assim.

NHibernate é "legal", mas não pra tudo e não com tudo. Outras opções de persistência também podem ser legais, mas nada como abrir o Query Builder direto do VS.NET e criar a sua query facilmente sabendo que ela estará encapsulada dentro de um método de um objeto gerado automaticamente (TableAdapter), e que ela tera como resultado um DataTable, que pode ser facilmente trabalhado...

É bem verdade que essa é uma solução onde a performance pode deixar a desejar quando trabalhamos em um ambiente "Enterprise", mas experimente trabalhar de forma errada com o NHibernate... convenhamos, quando temos uma aplicação relativamente simples não vejo mal nenhum em usar extensivelmente a injustiçada dobradinha DataSet/TableAdapters. Vamos ver o que vem por aí nas próximas versões do .NET.