Modelo de Arquitetura MVC + EF

[Eduardo Pires]

Pessoal,

Lendo um pouco sobre a serie patterns & practices da Microsoft, encontrei esse guia "Client-Side Web Development for Modern Browsers" e sugerem esse modelo (imagem).

Cada um tem uma forma de fazer, acredito que não muito diferente dessa que estou abordando, mas e ai o que acham?

Ao meu ver está ok, atende a prática do DDD, faz uma separação lógica das camadas sem frescuras, como um modelo inicial eu gostei.
Agora gostaria de propor um bate papo com vocês, se acrescentariam mais algo ou se conseguem enxergar algum possível problema em obedecer esse modelo.

No mais, fica como sugestão para quem não adotou nenhum modelo.

O guia todo esta aqui: http://msdn.microsoft.com/en-us/library/hh404093.aspx

[ ]'s

[Mário Meyrelles]

A única coisa que não curti muito é a utilização de DataAnnotations para validação. Mas atende tb.

Mas de resto parece atender sim. O interessante é que tem muitas coisas a mais nesse projeto - acho que vale a pena estudá-lo com mais calma...

2012/9/3 Heitor Estrela <heitor...@gmail.com>

Gostei muito do modelo, ultimamente venho utilizando basicamente uma arquitetura parecida só o que mudo é o Data Access onde uso o MongoDB.

Uma projeto de testes unitários também vai bem. 

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

[Guilherme de Souza]

Mario vc poderia dizer qual o problema em utilizar DataAnnotations?

Em 4 de setembro de 2012 09:11, Mário Meyrelles
<mariome...@gmail.com> escreveu:

--
Guilherme Rares
Consultor de Tecnologia
Cel: (11) 7368-8469

[Mário Meyrelles]

Não é problema nenhum. Mas acredito que o uso do Fluent Validation torna muito mais flexível a criação de regras de validação de tela. Regras ligeiramente mais complexas como "DataFim >= DataInício" já ficam mais chatas de fazer só com data annotations. Talvez dê pra fazer mas não sei como se faz rs.

2012/9/4 Guilherme de Souza <guic...@gmail.com>

[Guilherme de Souza]

Entendi Mario, porém este ex que vc deu é bem simples de ser
implementado com DataAnnatations;

Em 4 de setembro de 2012 09:30, Mário Meyrelles
<mariome...@gmail.com> escreveu:

[Renato Cantarino]

O exemplo das datas, tem q ser implementada um classe que herda de RangeAtributte

Att,

Renato Cantarino

[Mário Meyrelles]

Dando uma olhada, eu vi que é realmente muito simples.

Mas ainda assim, usando o fluent você consegue definir esta regra em apenas uma única linha, sem ter que herdar nada. De qualquer forma, os 2 jeitos atendem e não vejo problema em combinar as 2 técnicas para gerar código mais enxuto.

2012/9/4 Renato Cantarino <renato.c...@gmail.com>

[Renato Cantarino]

Realmente, 1 linha é melhor do que uma classe.

[Fernando Mondo]

Eu gosto do Fluent porque eu suo Child View Model, e encho de conficionais (When) além de acesso a banco.

Porém o correto é que eu deixa-se estas validações para outra camada, então acho que o  Fluent me acaba levando tentenado a uma Smart UI, infelizmente...

[Eduardo Pires]

@heitorestrela, Eu não considero projeto de testes como parte da arquitetura, mas com certeza tem sim :)

Eu uso DataAnnotations, no caso de Fluent Validation (nunca usei) como utilizo classes POCO será que não fere o conceito?

2012/9/4 Fernando Mondo <fernand...@gmail.com>

[Winston Pacheco Junior]

Você usa repository Eduardo?

[Eduardo Pires]

O pattern repository? Estou pensando em usar nesse projeto que estou começando...

2012/9/4 Winston Pacheco Junior <winston...@gmail.com>

[Winston Pacheco Junior]

Porque desse desenho, acredito q é a parte mais inútil e incoerente...

O Entity Framework já é um unit of work, porque você teria que esconder ele do seu negócio?

[Fernando Mondo]

Winston, repository facilita os teste e deixa seu software muito mais legivel, pois as vezes o lambda pode ser complexo demais, além de se repetir em varios pontos da aplicação...

[Eduardo Pires]

O beneficio desse pattern é abordado naquele link, já vi pessoas defendendo e outras até lhe considerando um anti pattern, como o Fernando falou os benefícios são bem estes mesmos:

The Repository pattern assists in separating data storage concerns from the application logic. This pattern is especially beneficial when you use the ADO.NET Entity Framework because it allows you to hide ADO.NET Entity Framework-specific classes such as DbContext and DbSet, to optimize the shape of the data returned to the application, to coordinate updates, and to unit test your application without requiring access to physical data storage. See the "Further Reading" section for a formal definition of the repository pattern. 

2012/9/4 Fernando Mondo <fernand...@gmail.com>

[Mário Meyrelles]

Acho que vale a pena fazer algum esforço para encapsular o repositório em formas mais fáceis de se entender para o consumidor final. Tipo, não vale a pena só criar os métodos básicos como GetAll, GetById, Find, etc. Compensa criar métodos mais claros como "ObterUsuáriosAtivos", "ObterClientesPrimeiraCompra", etc... Mas é um custo, que sem dúvida, precisa ser analisado.

Um pattern que eu já vi nesta lista é criar extension methods no repositório para isso rs. Nunca fiz assim, mas achei a idéia interessante.

O que não pode é lógica de manipular o repositório se espalhar pelo código todo. Aí pouco adianta ter um repositório - é mais fácil expor um ISession / DbContext-DbSet da vida.

2012/9/5 Eduardo Pires <hea...@gmail.com>

[Winston Pacheco Junior]

Enfim, nesse caso posso dizer que é gosto. Eu não gosto.

Quanto aos testes, é possível testar numa boa usando ISession...

O Entity Framework ainda tem essa coisa de DbSet? Eu sempre achei q eles tinham se enganado no design disso e iam tirar nas versões futuras. O DbContext tem os DbSet's dentro dele? Se isso ainda funciona dessa forma, acho importante o Repository.

A ideia dos Extensions Methods eu acho legal, principalmente se a query se repete.

Uma curiosidade: esse projeto que você está fazendo é pra estudar ou é "pra valer"? Se for para estudar e aprender, você deveria tentar também outras formas de acesso a dados, muitas vezes até SQL direto é melhor. Além disso existem os Micro ORMs. Hoje em dia só não tem opção quem não quer.

[Mário Meyrelles]

Olá Winston,

Eu entendi que é mais fácil usar um ISession do que um DbContext para testar. É isso mesmo?

Respondendo, sim - ainda o DbSet fica dentro de um DbContext. Pq vc não gosta disso?

2012/9/5 Winston Pacheco Junior <winston...@gmail.com>

[Winston Pacheco Junior]

Quanto ao ISession, eu acho mais fácil "mocar" uma interface que uma classe concreta.

Porque eu acho que a Session poderia, pra não dizer que deveria, ser mais inteligente do que isso. Se eu já tenho o mapeamento do objeto, porque eu deveria criar uma classe pra registrar na minha Session que eu mapeei um objeto? Porque eu não utilizaria Generics como em diversas outras soluções de UoW? Sinceramente não vejo uma razão pra isso.

[Mário Meyrelles]

Bem, no caso do EF, com Code First, não tem mapeamento (a não ser que vc queria). Aí o DbSet representa o que o será criado no banco de dados. E o DbSet é um DbSet<T> então o repositório consegue ficar genérico. E na  prática, o EF ja é por si uma solução UoW com Generics. Acho que as versões mais atuais do EF tão mais bacanas.

Quanto a mocar o ISession, não vejo grande utilidade nisso...  Mas eu já vi muita gente fazer isso. Para mim é algo como testar o martelo para então testar se o prego foi martelado adequadamente.

[Winston Pacheco Junior]

c tá falando de fazer somente testes integrados?