Atenção: esse artigo tem uma palestra complementar. Clique e assista!

POCO quer dizer Plain Old CLR Object, e significa que nossas entidades de negócio devem ser o mais simples possível, sem nenhuma dependência de ferramentas externas. Confira um exemplo de como é uma classe modelada no estilo POCO na Listagem 1.

Listagem 1. Simples exemplo de classe POCO

namespace EFv4Poco.Dominio { public class Cliente { public int ID { get; set; } public string Nome { get; set; } public string Endereco { get; set; } public string Telefone { get; set; } } }

Veja que a classe não herda de ninguém, não implementa nenhum método e possui apenas propriedades que definem a estrutura de um cliente. Esse é o POCO mais radical que se pode fazer. Implementações menos radicais também são consideradas POCO, como por exemplo, herdar de uma entidade base, implementar uma interface, ou algum método que realize alguma tarefa específica com o cliente. Tudo isso desde que não haja nenhuma dependência com outras camadas da aplicação e ferramentas externas. Ou seja, a ideia do POCO é que tenha um modelo de entidades totalmente independente do mundo externo.

Mas qual é o benefício disso? Por que se fala tanto em ter uma camada de domínio da aplicação, desacoplada do resto? A resposta é simples. O domínio da aplicação, onde temos o modelo de entidades, assim como a modelagem das regras de negócio, é como o motor de um carro. E nós queremos construir um carro que, quando quebrar uma roda, seja necessário trocar apenas a roda e não o motor. Se você deixar o motor do carro acoplado à roda, toda vez que tiver que trocar a roda terá que trocar o motor também.

É isso que acontece em muitas aplicações hoje em dia. Muitos projetos precisam ser refeitos inteiramente porque o domínio da aplicação está espalhado entre as camadas e depende de todo tipo de tecnologia, como banco de dados, ferramentas de persistência e até da camada de apresentação. E como as tecnologias não param de surgir, onde temos novidades praticamente a cada seis meses, é importante que comecemos a planejar nossas aplicações para sobreviver a essas mudanças, senão vamos viver recriando o motor dos nossos projetos, toda vez que surge uma roda melhor no mercado.

POCO é uma boa prática voltada para isso. Por si só ele não resolve esse problema, é preciso aliar a ele uma série de boas práticas e princípios que o DDD ensina. Mas ele é uma das principais técnicas para atingirmos este objetivo.

A primeira versão do ADO.NET Entity Framework, que surgiu no Service Pack 1 do .NET Framework 3.5, não permite uma modelagem POCO. Com ele nosso modelo de entidades, e consequentemente o domínio da aplicação, fica fortemente acoplado ao Entity Framework. Isso é ruim se você levar em conta que o Entity Framework é uma “roda”, e que “rodas” melhores certamente surgirão no futuro.

Para aqueles que acreditam que o Entity Framework não precisará ser substituído no futuro, acoplar seu domínio a ele talvez não seja um problema, e uma implementação POCO não seja necessariamente importante. Mas a história nos mostra que novos “Entity Frameworks” surgirão, e que é bem melhor tratá-los como rodas e não como parte do motor.

A alternativa mais lógica para quem procura uma arquitetura desacoplada é o NHibernate, que desde o seu surgimento permite uma modelagem ao estilo POCO, e portanto permite a modelagem de um domínio totalmente isolado do restante da aplicação.

E é também para atender a essa necessidade que o ADO.NET Entity Framework 4.0 nos traz recursos para uma modelagem POCO. Vamos ver nas próximas páginas algumas formas de se fazer uma modelagem POCO com o EFv4.