Como lidar com modelo de exibição com várias raízes agregado?

Question

No momento, eu tenho muito mal moda modelo de vista.

Aulas olhares como este =>

 public class AccountActionsForm
    {
        public Reader Reader { get; set; }
        //something...
    }

O problema é que esse tipo de leitor vem de modelo de domínio (violação do SRP).

Basicamente, eu estou procurando dicas de design (ou seja, é uma vista de modelo boa idéia de divisão para entradas / saídas?) Como fazer o meu modelo de vista fricção-menos e desenvolvedor amigável (ie - mapeamento deve funcionar automaticamente usando o controlador classe base)?

Eu estou ciente de quadro AutoMapper e eu estou provavelmente vai usá-lo.

Assim, uma vez mais - o que são dicas comuns ao tentar criar modelo de visão adequada? Como estruturá-la? Como mapeamento é feito quando há uma entrada múltipla objeto de domínio necessário?

---

Estou confuso sobre casos em vista precisa de dados de mais de 1 raiz agregada. Estou criando aplicativo que tem entidades como Biblioteca, Reader, BibliographicRecord etc.

No meu caso -. A nível de domínio, não faz sentido para agrupar todos esses 3 tipos em LibraryReaderThatHasOrderedSomeBooks ou outros enfeites, mas a visão que deve exibir a lista de livros encomendados para leitor específico na biblioteca específica precisa de todos eles

Assim - ele parece muito bem para criar vista OrderedBooksList com vista OrderedBooksListModel modelo embaixo que detém modelos LibraryOutput, ReaderOutput e vista BibliographicRecordOutput. Ou ainda melhor - OrderedBooksListModel modelo de vista, que aproveita achatamento técnica e tem adereços como ReaderFirstName, LibraryName etc.

Mas isso leva a problemas de mapeamento porque há mais de uma entrada.
Não é de 1: 1 relação mais onde eu chutar em apenas uma raiz agregada
. Isto significa que meu modelo de domínio é uma espécie de errado?

E o que dizer de vista campos do modelo que vivem exclusivamente na camada de interface do usuário (ou seja enumeração que indica guia marcada)?

este que todo mundo faz em tal um dos casos?

 FooBarViewData fbvd = new FooBarViewData();
   fbvd.Foo = new Foo(){ A = "aaa"};
   fbvd.Bar = new Bar(){ B = "bbb"};
   return View(fbvd);

Eu não estou disposto a fazer isso => ??

var fbvd = new FooBarViewData();
   fbvd.FooOutput =  _mapper.Map<Foo,FooOutput>(new Foo(){ A = "aaa"});
   fbvd.BarOutput = _mapper.Map<Bar,BarOutput>(new Bar(){ B = "bbb"});
   return View(fbvd);

Parece que um monte de escrever. :)

---

a leitura deste no momento. E este .

---

Ok. Eu pensei sobre esta questão muito e sim - adicionando outra camada de abstração parece ser uma solução =>

Assim - na minha mente isso já funciona, agora é tempo para alguns brinca.

ty Jimmy

Answer 1

É difícil definir tudo isso, mas aqui vai. Nós gostamos de separar o que nós chamamos o que o Ver vê do que o Controlador constrói. The View vê uma achatada, objeto DTO-like com morte cerebral. Nós chamamos isso de vista do modelo.

No lado do controlador, estamos a construir uma rica gráfico do que é necessário para construir o Model View. Isto pode ser apenas um único raiz agregada, ou pode ser uma composição de várias raízes agregado. Todos estes juntos combinam no que chamamos de modelo de apresentação. Às vezes, o modelo de apresentação é apenas a nossa persistência (Domain) Modelo, mas às vezes é um novo objeto completamente. No entanto, o que nós encontramos na prática é que se precisa para construir um composto modelo de apresentação, ele tende a tornar-se um ímã para o comportamento relacionado.

No seu exemplo, eu criar um ViewFooBarModel, e uma ViewFooBarViewModel (ou ViewFooBarModelDto). Posso, então, falar sobre ViewFooBarModel no meu controlador, e em seguida, contar com mapeamento para achatar o que eu preciso deste modelo intermediário com AutoMapper.

Answer 2

Aqui está um item que ocorreu-nos depois que tinha sido lutando com alternativas para um longo período de tempo:. renderização de dados é diferente de receber dados

Nós usamos ViewModels para processar dados, mas rapidamente descobriu-se que quando ele veio para a recepção de dados através de formulários de postagem e semelhantes, não poderíamos realmente fazer nossas ViewModels encaixar o conceito de ModelBinding. A principal razão é que a ida e volta para o navegador muitas vezes envolve a perda de dados.

Como um exemplo, apesar de usar ViewModels, eles são baseados em dados de domínio objetos reais, mas não pode expor todos os dados de um objeto de domínio. Isto significa que pode não ser capaz de reconstruir imediatamente um objeto de domínio subjacente a partir dos dados postados pelo navegador.

Em vez disso, precisamos mapeadores de uso e repositórios para recuperar domínio completo objetos a partir dos dados publicados.

Antes nós percebemos isso, nós lutamos muito com a tentar implementar ModelBinders personalizados que poderia reconstruir um objeto completo domínio ou ViewModel a partir dos dados postados, mas agora temos separado PostModels que o modelo de como podemos receber dados .

Nós usamos mapeadores e serviços abstratas para mapear uma PostModel para um objeto de domínio - e então, talvez, de volta a um ViewModel, se necessário

.

Answer 3

Enquanto ele não pode fazer sentido para grupo não relacionados Entidades (ou melhor, seus repositórios) em um objeto de domínio ou serviço, pode fazer muito sentido para agrupá-los na camada de apresentação.

Assim como nós construímos ViewModels personalizados que representa dados de domínio de uma forma particularmente adequado para uma aplicação específica, também usamos personalizados serviços de camada de apresentação que combinem coisas conforme necessário. Estes serviços são muito mais ad-hoc, porque eles só existem para apoiar um determinado ponto de vista.

Muitas vezes, vamos esconder esse serviço atrás de uma interface de modo que a implementação concreta é livre para usar qualquer alheios injetado Domínio objetos que precisa para compor o resultado desejado.