Algumas pessoas já me perguntaram o que eu acho do sample feito com MVC do Rob Conery, o MVC Storefront, que está listado inclusive no site do ASP.Net como exemplo de aplicação MVC. E eu já disse mais de uma vez: eu não gostei. Eu parei de assistir antes do décimo episódio, e ele agora está no vigésimo quinto. Eu parei de assistir porque não gostei da arquitetura que ele estava montando, já tinha visto que ia dar problema, e que não me acrescentava. Se for só para ver um demo de ASP.Net MVC tenho como fazer isso em outros samples. Quando vi o que ele estava chamando de “repositório” estava na cara que não ia dar boa coisa. As chamadas ao banco vazavam para a interface, o repositório era burro, e totalmente anti-DDD. Ele usou LINQ to SQL, e é um problema que acho que vai acontecer em muita aplicação por aí. Acho que chega a ser até um desserviço, vai ensinar errado…

Bom, levou vinte e cinco episódios e, depois de um monte de gente dizer para o Rob que ele estava utilizando alguns conceitos errados, nomes errados, padrões não adequados, ele parece ter ouvido. No post sobre o assunto ele menciona que vai passar a usar DDD. Segundo o vídeo, ele vai refazer todo o aplicativo. Vi algumas coisas que gostei, ele está aplicando mais padrões do que antes, e os está aplicando corretamente, então a aplicação está ficando mais estruturada.

Mas vi também um grande problema, e é algo que acontece quando você insiste em conciliar coisas que não vão tão bem juntas: ele continua usando LINQ to SQL, mas também está usando POCOs. Por essa escolha ele é obrigado a mapear os objetos criados pelo LINQ to SQL para os objetos de domínio. Isso dá o maior trabalhão, para cada operação ele primeiro mapeia, depois faz o que tem que fazer. Além de ter um overhead razoável, já que a cópia envolve tipos de valor e há criação de novos valores na memória, há também pelo menos dois objetos para representar cada entidade: o objeto de domínio, e o objeto do LINQ to SQL. DDD vai muito bem com POCOs, mas LINQ to SQL não. Nesse caso, não há dúvida, um NHibernate cairia muito melhor. Na minha opinião, ou mudaria os repositórios para NHibernate, ou desiste dos POCOs e usa mesmo os objetos do LINQ to SQL. Os dois juntos não dá. Vai tornar a rotina de manutenção dos repositórios complicada e propensa a erros. Vi uns métodos lá com umas 20 linhas de mapeamento. Isso não tem como dar coisa boa.

Mas o passo é bom. Vou acompanhar os próximos capítulos agora. No próximo tem uma ajuda do Ayende, e já rolou uma com o David Laribee, ou seja, ele está com ajuda de gente de peso.