Solucionado (ver solução)
Solucionado
(ver solução)
3
respostas

[DataContract] x Model

Não seria melhor termos as classes de model no tipo ViewModel para aplicar o [DataContract], para não "misturarmos" o model(DB) com requisitos da camada de visualização? E também, criar uma classe BaseModel somente com o Id e fazer com que outras herdem dela, somente por conta da camada de visualização, não é algo que fere o sentido de herança? Visto que semanticamente não faz muito sentido. Eu entendi o porque de ter feito isso, mas questiono o design gerado.

3 respostas

Olá Diogo,

de fato sempre é uma boa ideia trabalhar com ViewModels quando estamos querendo nos referencias a camada de visualização, mas também é necessário usar com bom senso. Se sua classe View Model for ficar exatamente igual a sua classe de entidade do banco, por que já não usar direto a entidade do banco? Se não você acabará tendo bastante retrabalho e duplicatas/repetição de código. Geralmente eu opto por usar a View Model quando realmente ocorre uma ruptura/divergência entre o que existe na visualização e a entidade do banco. Um exemplo que eu gosto de usar é cadastro de usuário, geralmente no cadastro do usuário ele pede o login, senha e confirmação de senha, enquanto no modelo salvo no banco só preciso do login e senha. Neste caso eu faria uma View Model para representar o formulário de login e uso isso para criar o usuário.

Quanto a BaseModel, pela ideia que eu percebi de criar esta classe mãe não seria nem por causa da camada de visualização, mas justamente por conta de que toda entidade precisa de uma propriedade Id. Dessa forma, todas as classes que podem ser salvas no banco acabam sendo BaseModel (regrinha do "é um" para definir heranças).

Entendo. No exemplo dado por você, seria errado usar herança entre as classes Usuario e ViewModelUsuario?

Quanto ao BaseModel eu entendo que não seria para a camada de visualização e também entendi o propósito usado pelo instrutor, o que quis me referir é quanto a questão de ser usar herança quando de fato não temos um relacionamento de herança propriamente dito, pois semânticamente, neste caso, ao meu ver, não faz sentido.

Obrigado.

solução!

Geralmente entre o Usuario e a ViewModelUsuario eu evito usar herança por conta que o modelo Usuario pode evoluir com o tempo. Se, por exemplo, a ViewModelUsuario herda de Usuario, que tem inicialmente login e senha, e assim na view model eu apenas acrescento apenas a confirmação de senha. Só que no futuro se eu aumentar o meu modelo de Usuário colocando uma lista de produtos que ele comprou.Neste caso a ViewModelUsuario passaria a ter esta lista também, o que não faria muito sentido dado que a ViewModelUsuario serve para o cadastro, que é login, senha e confirmação de senha. Por isso que neste caso a relação de herança não faria tanto sentido.

Já quanto a BaseModel, uma das vantagens de se usar ela é que nas classes filhas você não deixa resquícios de bancos de dados dentro dela. Quando usamos algum framework ORM, a maioria das classes precisam ganhar uma propriedade Id apenas para o orm conseguir criar as tabelas e fazer os relacionamentos. Mas Id é coisa de banco, não de orientação a objetos. Pelo menos com a BaseModel isolamos o que é referente a banco num lugar só e as filhas trabalham apenas com composições.

Outra vantagem de fazer a mãe de todos aqueles que vão para banco de dados é que você consegue criar o Dao genérico, que seria uma classe mãe de todos os Daos e já define os métodos básicos como insert, delete, update e busca por Id.

Quer mergulhar em tecnologia e aprendizagem?

Receba a newsletter que o nosso CEO escreve pessoalmente, com insights do mercado de trabalho, ciência e desenvolvimento de software