[PADRÃO DE PROJETO] Comunicação do Backend com camada de Persistência
Closed this issue · 15 comments
Contexto
Comunicação do backend com a camada de dados (englobando as classes models, a criação da comunicação com o backend e os serviços de persistência: criação, deleção etc)
Tarefas
- Revisitar o Diagrama de Classes:
- Ajustes do feedback pós-entrega
- Inclusão das classes de comunicação com o Banco de Dados
- Revisitar o Diagrama de Pacotes
- Ajustes do feedback pós-entrega
- Inclusão dos pacotes usados na modelagem
- Definir um padrão GoF: proxy
- Definir um padrão GRASP, a partir do GoF
- Esboço individual da modelagem
- Parear para modelar o problema
Para o momento inicial, eu e o @nszchagas decidimos por fazer algumas correções no diagrama de classes (sinalizamos em vermelho em primeiro momento) para que possamos futuramente melhor trabalhar com os modelos. Segue o link para o diagrama
https://lucid.app/lucidchart/4dd6a296-dbea-46b7-8bb7-b515fbc1fb05/edit?viewport_loc=347%2C-428%2C1480%2C621%2CHWEp-vi-RSFO&invitationId=inv_32177c76-50f9-40b1-95df-7711173e673f
deixei uma branch com o nome de "ComunicaçãoBackendPersistência" para trabalharmos no pages caso quisermos já documentar lá dentro
Dos padrões que eu estudei (Decorator e Proxy), o que mais faz sentido para o nosso contexto é o Proxy, caso nosso sistema tenha a necessidade de manter algo meio que em cache, como o login, informações do banco de dados, etc.
Acredito que não utilizaremos o decorator mesmo, vista que não vejo alterarmos vários objetos dinâmicamente em nosso escopo (talvez para o pessoal do Front)
Dos padrões GRASP que estudei, acredito que usar o Baixo Acoplamento (Low Coupling) e a Alta Coesão (High Cohesion) podem ser aplicados como base nas modificações do diagrama de classes, já que eles colocam pontos importantes nas mudanças
Boa noite pessoal! Estou dando mais uma mexida no diagrama de classes, dei uma revisada na classe Avaliacao e ficou dessa forma:
Já comecei a esbarrar nos problemas resolvidos pelo GRASP, criei essa classe mídia, a ser especializada em vídeo, foto (e talvez áudios?), e aí me surgiu a dúvida: quem cria a mídia? Na hora que criarmos a avaliação, a mídia já será criada?
E temos outro problema, o usuário pode ou não estar logado pra fazer a avaliação, então eu pensei em criarmos uma classe Autor pra avaliação, com a seguinte estrutura:
Mas algo me soa errado nessa implementação, vocês tem alguma sugestão?
Acredito que o autor e usuário talvez possam ter uma classe pai, em que eles herdam atributos em comum, não vejo como uma agregação, porque o autor não depende de um usuário cadastrado
Dei mais uma mexida nas classes, pra ir adequando pro diagrama de pacotes e o modelo MVC que estamos utilizando:
Controller
A camada controller possui uma BaseService pra padronizar as comunicações dos serviços com o Banco de Dados, ela é herdada pelas três classes de serviço que precisamos para gerenciar as avaliações, produtoService, avaliacaoService e compraService. Todas as services tem as operações do CRUD, abstratas na classe Pai e sobrescritas nas classes filhas.
Model
Tem uma BaseEntidate (usada na BaseService), que é estendida pelas models Produto, Avaliacao e Compra. Ainda não consegui visualizar o que as models tem em comum, mas provavelmente terão em comum o id, para quando a gente utilizar o "deletar(id)" poder pegar o id da BaseEntidade.
Além disso, há também as classes de mídias, que havia citado antes:
Autenticação
Para resolver nossos problemas com autorização, quem pode autorizar avaliação, quem pode criar, e onde a gente pode definir uma classe pai para usuário e autor, igual a @luiza-esteves sugeriu, agrupei essas classes mais relacionadas nesse pacote autenticação
Tirei todos os relacionamentos porque acho válido repensá-los com essas últimas mudanças, acabou que ficou um pouco confuso, igual a agregação que estava ali no usuário.
Criei duas branches pra gente dividir o trabalho e minimizar os conflitos: back-gof e back-grasp
Padrões de Projeto GRASP
Realizei uma análise inicial dos Padrões de Projeto GRASP e como eles podem se encaixar no escopo de nosso projeto
Considerações iniciais dos membros
Considerações adicionais
Obs.: Dentro do contexto citado pelo Nicolas anteriormente nessa Issue, talvez realmente a utilização do padrão GRASP Especialista faça sentido mesmo.
Boa tarde pessoal, depois de uns diálogos com o Luquinhas pensei em uma modelagem em baixa fidelidade das classes do proxy em relação ao usuário:
Casa bem com a modelagem que temos no pacote de segurança, a implementação do proxy é por meio de uma interface realizada por duas classes, uma proxy e uma "real", e no proxy há um controle de acesso. Pensei em fazer esse controle de acesso com um enum, e a depender do valor do enum retornarmos só os dados de usuário necessários para a ação. Aí lá no construtor do AvaliacaoService pegaremos os dados do usuário utilizando a interface do usuário.
O que acham? Estando ok passo essa modelagem para a versão digital para incluirmos na documentação.
@nszchagas Acho que está OK, so falta adicionar o TipoAcesso tipoAcesso ali no usuário da direita, que pode ser renomeada para UsuarioImplementado para nao confundir com a interface Usuário
@nszchagas Acho que está OK, so falta adicionar o TipoAcesso tipoAcesso ali no usuário da direita, que pode ser renomeada para UsuarioImplementado para nao confundir com a interface Usuário
Com isso, o método checarAcesso ja vai estar "implementado" quando instanciar o UsuarioProxy
Tamos com uma base um pouco mais consolidada relacionada a implementação dos GOFs, vamos ter que fazer uma força tarefa maior relacionada ao Grasp agora.
Bom dia pessoal!
Aqui está a modelagem do proxy, caso queiram alterar algo me avisem para eu gerar a imagem novamente para a documentação. Já inseri no documento também, e estou escrevendo a parte de modelagem e participantes.
