Dva: Como implementar o aninhamento de modelo (modularização)?

Criado em 17 fev. 2017  ·  14Comentários  ·  Fonte: dvajs/dva

Existe uma grande demanda por modularidade,

Se houver apenas um modelo de primeiro nível, pode haver muitos modelos, o que não conduz à modularização

Não sabe como alcançar a modularização do modelo?

faq question

Comentários muito úteis

Essa questão está um pouco entendida, ontem a gente discutiu. É principalmente sobre o significado do modelo, existem duas tendências: seguir a visão e seguir a entidade empresarial.

Do ponto de vista do design atual, deveria ser mais adequado seguir a vista, porque o estado de cada modelo é isolado e tudo no modelo segue o seu próprio estado.A partir desta perspectiva, é realmente melhor seguir a vista. Neste caso, o significado de modelo é modelo de exibição.

Mas, desta forma, essas adições, exclusões, efeitos de verificação e modificação de negócios usados ​​pelo modelo podem existir em todos os modelos usados, por exemplo:

Existem visualizações ABC, entidades comerciais XYZ, onde:

A usa CRUD de XY
B usa o CRUD de YZ
C usa o CRUD de XZ

Nosso modelo é projetado para seguir a visão ABC e deve haver alguns efeitos de redundância nele. Por exemplo, Y existe em AB ao mesmo tempo e pode haver redundância no código. De outro ponto de vista, o uso de Y no próprio AB não deve considerar a reutilização, e o processo de chamada a ser reutilizado deve ser colocado no próximo nível, ou seja, serviço.

Assim, a estrutura organizacional passa a ser:

  a
  b
  c
service
  x
  y
  z

E a estrutura do modelo A:

{
  effects: {
    *x() {
      yield call(serviceX);
    },
    *y() {
      yield call(serviceY);
    }
  }
}

A estrutura do modelo B:

{
  effects: {
    *y() {
      yield call(serviceY);
    },
    *z() {
      yield call(serviceZ);
    }
  }
}

Posteriormente, escreverei uma demonstração mais orientada para os negócios e darei algumas sugestões para o uso de cenários

Todos 14 comentários

Negócios são assim,
Por exemplo, existem 5 produtos relativamente independentes no aplicativo e cada produto tem um modelo relativamente independente.

Neste caso, apenas uma única camada do modelo ficará muito apertada

Claro, ele também pode ser distinguido no namespace, mas atualmente o namespace será usado diretamente como o nome do estado (símbolos especiais como . não podem ser usados)

Apenas uma única camada do modelo ficará muito apertada

Não entendi

@codering

Olhando para o documento, o modelo tem apenas uma camada fisicamente. Se houver um grande número de modelos, é provável que haja um conflito de namespace com o mesmo nome (especialmente para grandes projetos, alguns modelos têm a mesma semântica). desta vez, eles podem ter que estar no namespace., Adicione o prefixo predominantemente como uma distinção entre os módulos.

Então, eu gostaria de perguntar se existe um esquema melhor de aninhamento de modelo ou modularização?

Não é recomendado aninhar muito profundamente no estado. Se você ainda aninhar o modelo, será mais complicado. Parece que há um problema com o design.
Eu não entendo a pergunta, você pode me dar uma demonstração simples?

Essa questão está um pouco entendida, ontem a gente discutiu. É principalmente sobre o significado do modelo, existem duas tendências: seguir a visão e seguir a entidade empresarial.

Do ponto de vista do design atual, deveria ser mais adequado seguir a vista, porque o estado de cada modelo é isolado e tudo no modelo segue o seu próprio estado.A partir desta perspectiva, é realmente melhor seguir a vista. Neste caso, o significado de modelo é modelo de exibição.

Mas, desta forma, essas adições, exclusões, efeitos de verificação e modificação de negócios usados ​​pelo modelo podem existir em todos os modelos usados, por exemplo:

Existem visualizações ABC, entidades comerciais XYZ, onde:

A usa CRUD de XY
B usa o CRUD de YZ
C usa o CRUD de XZ

Nosso modelo é projetado para seguir a visão ABC e deve haver alguns efeitos de redundância nele. Por exemplo, Y existe em AB ao mesmo tempo e pode haver redundância no código. De outro ponto de vista, o uso de Y no próprio AB não deve considerar a reutilização, e o processo de chamada a ser reutilizado deve ser colocado no próximo nível, ou seja, serviço.

Assim, a estrutura organizacional passa a ser:

  a
  b
  c
service
  x
  y
  z

E a estrutura do modelo A:

{
  effects: {
    *x() {
      yield call(serviceX);
    },
    *y() {
      yield call(serviceY);
    }
  }
}

A estrutura do modelo B:

{
  effects: {
    *y() {
      yield call(serviceY);
    },
    *z() {
      yield call(serviceZ);
    }
  }
}

Posteriormente, escreverei uma demonstração mais orientada para os negócios e darei algumas sugestões para o uso de cenários

@xufei precisa de orientação como o tio

@xufei Você pode aprender com sua demonstração?Estou preocupado com isso recentemente

O @xufei demo tem isso?

O @xufei demo tem isso?

Eu acho que é mais razoável ter um modelo de negócio e um modelo de visão.Por exemplo, o usuário atual pode ter um modelo de usuário para processamento global.
Se outros componentes envolverem informações do usuário atual, basta conectar-se diretamente ao modelo do usuário.Depende das necessidades do negócio

@ liSong5713 Lista de usuários clicada na lista de detalhes do usuário, detalhes do usuário clicados no gerenciamento de chaves se devem ser colocados no mesmo modelo de usuário

@lwbGH Isso depende das responsabilidades do seu modelo. O modelo do usuário pode ser as informações básicas e comumente usadas do usuário conectado no momento. Se você quiser alterar as informações detalhadas do usuário, como o registro da operação do usuário, essas informações podem ser completamente diferente do modelo. Acho que a divisão do modelo reside um pouco:
O grau de compartilhamento do estado dos componentes de nível , se uma página simples corresponder a um modelo de nível de página, será complicado

Claro, ele também pode ser distinguido no namespace, mas atualmente o namespace será usado diretamente como o nome do estado (símbolos especiais como . não podem ser usados)
. Não pode ser usado como uma chave, você pode usar _. Atualmente, estamos restritos ao namespace. Os modelos podem ser divididos em módulos por visão e negócio, mas o namespace é restrito por "folder_file name".
image

Esta página foi útil?
0 / 5 - 0 avaliações