Comments (6)
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.
Related Issues (20)
- For larger project HOT 1
- Confused about the folder structure. HOT 1
- A working minimal example would be greatly appreciated HOT 7
- Where do the dialogs go? HOT 2
- Question regarding the getx pattern HOT 3
- Do we really need the repository? HOT 2
- Dúvida no conceito de módulo HOT 5
- Duplication of initial page HOT 1
- Dúvida: onde ficariam as interfaces que são implementadas pelos `services`, `repositories` e `providers`? HOT 4
- Why is there only Android configuration under UI, IOS configuration? I don't think it makes a lot of sense HOT 1
- why folder views is double? HOT 2
- Shared controller is multiple views HOT 1
- why you dont getConnect as provider? HOT 4
- Modules... HOT 1
- Where would I put the StreamSubscription? HOT 2
- folder name: exEmples and exAmples HOT 1
- Example code HOT 1
- Site Translations HOT 4
- examples _and_ exemples? HOT 2
- Understanding the difference between Services and Providers, along with their interaction with Repositories HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from getx_pattern.