Eu só descobri há um mês a loucura deacessando diretamente entidades / modelos da camada de acesso a dados de um aplicativo de n camadas. Depois de ler sobre ViewModels enquanto estudava ASP.NET MVC, eu vim a entender que para fazer um aplicativo verdadeiramente extensível o modelo que interage com a camada de interface do usuário deve ser diferente daquele que a camada de acesso a dados tem acesso.
Mas e a camada de negócios? Devo ter também um conjunto diferente de modelos para minha camada de negócios? Para verdadeira separação de interesses, eu deveria ter um conjunto específico de modelos que sejam relevantes apenas para minha camada de negócios, de modo a não mexer em nenhuma entidade (possivelmente gerada por, por exemplo, a estrutura de entidade ou EJB) no DAL ou isso é um exagero?
Respostas:
0 para resposta № 1ASPO NET MVC é bem servido pela maneira Model-View-ViewModel (MVVM) de fazer as coisas. Isso significa que cada visualização recebe UM e APENAS UM ViewModel, que é um modelo em formato personalizado que é dedicado a servir essa Visualização.
Por exemplo, se você tiver uma visualização Pedidos que precise de alguns dados OrderDetail e Customer, crie um ViewModel que expõe apenas os dados dessas Entidades requeridos por essa Visualização. O ViewModel serve para agregar dados em conjunto de várias entidades (ou uma, conforme necessário).
Suas Entidades e lógica de negócios ficam "sob" a camada View / ViewModel e não devem estar cientes de sua implementação.
1 para resposta № 2
Sim você pode. No entanto, essa solução particular complica seu código e leva a um monte de POCOs que possuem propriedades e dados semelhantes, o que é inútil.
O ponto principal, no entanto, é apenas ter uma separação do objeto usado para renderizar sua visão e o objeto que você usa para representar os dados.