Dúvida sobre arquitetura de dados. about getx_pattern HOT 6 CLOSED

Certo, mas ainda está confuso as camadas de dominio e dados.

Você usa repository como uma abstração de dados/entidades/model... até aqui tudo bem, faz sentido.

Porém, ao adicionar provider como provedores de dados, tudo que pode fornecer dados para a sua aplicação, fica meio confuso já que o repository tem a mesma função... a não ser que os providers estejam uma camada acima dos repository... ou seja, o fluxo de dados seria:

                  Service
                 ^^^^^^^^^
view <-> controller <-> provider <-> repository <-> model

Obviamente model no fluxo é usado em todas camadas, como a representação dos dados. Agora minha dúvida está na diferença entre o repository e o provider. Se o provider for uma abstração do repository, contendo casos de uso para estar mais próximo da camada de visualização, eu entendi e está otimo...

Mas na estrutura de arquivos que mostrou agora, não me pareceu que é isso isso, a não ser que as pastas api db e arquivos sejam seus repositories... mas aí, cade os providers?

Sobre a nomemclatura, depois de trabalhar em alguns projetos grandes, eu prefiro trabalhar assim, mantenho a pasta/package com o nome da camada, e o nome do arquivo mais especifico do tipo do serviço que ta sendo usado, db/local/api/etc...

Abraço! Parabéns pelo trabalho.

from getx_pattern.

A nomenclatura que uso hoje é mais ideal para a forma estrutural de packages quando separamos os controllers da view, no formato de módulos com certeza essa é melhor.
api, db e arquivos, são provedores de dados, podemos ter varias apis fornecendo dados para a nossa aplicação esperando ser chamados por um repositório, é importante notar que o controller nunca sabe o que esta na api e vice versa, além da abstração, lembre-se da separação por entidades.
Podemos ter Usuários salvos no banco de dados, no shared preferences e um que é retornado da api.
Também podemos ter uma classe de api "nossa" com diversas chamadas, editar usuário, adicionar usuário, remover usuário, e também temos produtos, cadastrar produto, remover produto, todos sendo consumidos da mesma api.
Logo a manutenção fica difícil, que foi o que me levou a desenvolver a estrutura em modules, sendo assim toda nossa pasta data é nossa provedora de dados, neste momento podemos falar de model pra carregar nossas listas no controladores, ou caso a internet esteja offline do banco de dados, online direto da api, o nosso repository é responsável por prover esses dados aos nossos controladores de maneira organizada, UserRepository conterá as chamadas da api referentes, única e exclusivamente a essa entidade, ProdutosRepository apenas pelos produtos.
Foi apenas uma maneira de organizar melhor o código, antes o repository, assim como no bloc fazia os dois papéis, mas sempre achei errado essa comunicação direta controller <> api/db.
Imagine poder refatorar toda sua api para o firebase, sem precisar alterar as chamadas em cada controlador? Você já tem tudo organizado por entidades, poderá entrar no repository evidenciado e alterar as chamadas dele, sem precisar alterar direto no controller entendeu ?
Realmente é apenas uma classe que contem todas as chamadas responsáveis por dados crud/api por exemplo, e separados por entidades, uma classe com funções que redirecionam para outras funções.
Isso me ajuda em projetos grandes, se tenho de refatorar algo do usuario, primeiro procuro seu repositório para depois me direcionar direto pra chamada na api por exemplo.
Obrigado por contribuir, e pelas ideias, vamos discutir mais sobre isso...

from getx_pattern.

Sem contar do service que pode carregar serviços em tempo de execução, como consultar se a seção do usuário está ativa, pegar o id do usuário logado, também o torna um provedor de dados, esse sim mais próximo do controller, por ser um serviço/provedor, não um provedor apenas.
O problema é compactar essa estrutura de maneira modular sem uma quebra de fluxo muito grande, ou seja, se vc abrir seu module, vai criar sua page, depois seu controller, seu bind, sua rota ( ignore a ordem).
Mas depois disso tudo fica dependente de um fluxo, uma via de mão dupla, o controller se prender aos repositorios que por sua vez se prendem a api ( vou usar só api de exemplo mas entenda como db/ou um arquivo json com strings que vc ira consumir na aplicação), onde sua api, por sua vez, precisa converter os objetos json recebidos para um modelo conhecido da sua aplicação, nosso model.fromJson() por exemplo, a classe volta pra api, que retorna ao repository que retorna ao nosso controller. logo temos um fluxo fechado.
chamada controller > repository responsavel > api > conversão de dados para nossos modelos > retorno para repository > retorno para controller > exibir na view.
E isso sempre se repetirá, agora de maneira mais fácil ainda, já que nao temos que carregar nosso client http nos nossos repository mais, por usar o GetConnect em nosso provider.
Leia provider.dart como qualquer um desses do exemplo

from getx_pattern.

Agora entendi.

Os providers são a camada mais baixa, em contato com os recursos que serão consumidos (db/api/etc...)

Os repositories fazem uso dos providers para obter e tratar os dados.

Agora entendi o motivo da minha confusão, eu não estava confundindo apenas o service, mas a função do repository e do provider na minha cabeça são invertidas.

Nas poucas arquiteturas que estudei para web/desktop, o repository é a primeira camada após o banco, as vezes até com o uso dos antigos DAO (Data Access Objects)... no qual existe confusão nas buscas online aí tbm. Que também gerava confusão com os Services que é um nome bem genérico e confunde mesmo. Nas que já utilizei, nunca ouvi falar de arquitetura provider, só quando começei a entrar no mundo mobile mesmo. Que não faz muito tempo, tenho um background mais extenso em Java web/desktop.

Ta show. Muito obrigado pelas explicações.

Quando tiver algo pronto do outro projeto que está fazendo, gostaria de acompanhar.

from getx_pattern.

Olá Bruno, muito legal seu ponto de vista, me fez pensar em algumas coisas.
Estou transformando o getx_pattern, isso em outro projeto, em uma arquitetura única que poderá ser utilizada em vários tipos de código como a clean não somente no flutter, que comecei a pensar durante o desenvolvimento do getx pattern, portanto, há muitas "abordagens" diferentes aqui, daqui a algumas semanas devo publicar algo sobre, e esse é o contexto do pattern estar um pouco atrasado, mas adicionarei o services na documentação. Então vamos lá.
Existem várias interpretações sobre o nome dos repositórios(pastas) em sí, aqui eu tentei deixar isso de uma maneira mais declarativa e legivel o possível, mesmo que fosse na contramão de alguns patterns conhecidos, portanto existem diferenças pros seus objetivos.

Explicando a pasta DATA : Nesta pasta contem tudo relacionado a manipulação dos nossos dados, não quer dizer que você precise utilizar todos, a não ser repository <-> model <-> [provider] .
Service é um serviço na aplicação, mais especificamente no getx, você pode abstrair um auth_service por exemplo, disponibilizando seu usuário e seus dados por todo código com esse serviço.

Provider É o nome ao pé da letra, são todos seus provedores de dados, tudo que pode fornecer dados para a sua aplicação. Então você poderá usar todas ali dentro, umas maneira de dividir por exemplo, neste exermplo você tem mais de uma api, organizadas em uma pasta.

  -/provider
     --  /api
       ---  my_api.dart
       ---  via_cep_api.dart
       ---  pagarme_api.dart
     --  /db
         ---   meu_banco_de_dados.dart
     --  /arquivos
         ---  arquivo.json  

Repository
Talvez o maior problema na compreensão dos repositories é o motivo dele representar nossas entidades, além de ser a abstração de uma camada, ou seja, toda sua entidade do banco, precisa de um repository.
Basicamente um repository por model, ou seja, toda manipulação de dados iniciadas por um controlador, direcionada a uma api, tem que passar pelo repositório da entidade que será afetada no banco, sem que o controller saiba, facilitando a manutenção da api por exemplo, sem refletir diretamente na chamada ou na forma em que é consumida.
Além de abstrair nossa camada de api, organizar seu código, ele deixa sua aplicação mais legivel, tudo que afeta o usuário, ao invés de procurar numa porrada de apis com varias linhas, vá direto no repositório da entidade e procure pela função.
Sobre a proposta, irei atualizar a documentação assim que possível e também o exemplo.
Sobre a sua nomenclatura, eu achei muito legal, e acho que vou adotar, pois fica muito mais explicito já que esta contido dentro do modulo cidades, não precisaria nem dos nomes pra falar a verdade, eu deixo por fins didáticos, mas seria perfeito nao ter que ler até a _ para saber se é uma page ou controller ersrsrs, irei alterar a nomenclatura na atualização.
Muito obrigado por contribuir, caso tenha mais alguma dúvida, deixarei o post aberto por hoje.

from getx_pattern.

Exato, em outras abordagens o os services fazem o papel dos nossos providers e os providers o papel do nosso service.
Mas no flutter provider foi conhecido inicialmente por prover estados pra aplicação e etc, e pensei em melhorar a estrutura do bloc, e lá os repositories eram nossas apis com chamadas pra elas direto, só separei, mas precisava de uma medida, então resolvi separar por entidades e ficou limpo, ficou show.
Creio que assim fica mais intuitivo, repositorios ser apenas um repositorio mesmo de funções por entidades, provider provendo dados pra aplicação, seja externos ou internos, services distribuindo e servindo dados/ funções por toda a aplicação.
Sim, comecei o repositório, estou testando em outras abordagens, web e back end, além do fluttter mobile, com isso já vai dar pra começar e vou abrir o projeto, vc ficara sabendo espero sua ajuda.
Até mais ! Valeu !

from getx_pattern.