Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Fala pessoal, blz?
Confesso que estou bastante confuso com relação a esse assunto no geral, pois passei quase a tarde toda pesquisando sobre patterns, arquiteturas etc e meio que minha cabeça deu um nó haha
Entendo a necessidade de uma camada de serviço em uma aplicação, porém, estou um pouco confuso com a utilização em um caso específico. Gostaria de entender se um serviço precisa ser necessariamente relacionado a um model.
Em uma aplicação que estou desenvolvendo existe um model User, e o mesmo pode atuar de diversos tipos (stakeholder, support, agent etc) na aplicação. Isso é possível a partir de uma relação com o model a Role... Enfim.
Minha dúvida é com relação a(s) camada(s) de serviço(s) que deve(m) ser criada(s) para o model User. Devo criar um único serviço que trata todos os tipos de usuários possíveis, como UserService; ou um serviço para cada tipo de usuário, como UserService (sendo essa uma abstração ou não), AgentUserService, StakeholderUserService etc; ou um serviço para cada tipo de ação, como CreateUserService, UpdateStakeholderUserService etc.
Enfim, espero que não tenha ficado confuso, e se tiver ficado, provavelmente é um reflexo do quanto eu estou confuso nesse momento hahaha
Vlw pessoal, abraço!
@Gabriel Heming
Cada tipo de usuário terá um comportamento diferente no sistema, até mesmo no processo de criação.
Acredito que irei criar, além do serviço do usuário principal (abstração), irei gerar uma especialização para cada tipo de usuário, pois desta forma conseguirei separar melhor as responsabilidades de cada um.
Minha principal dúvida era se eu deveria me prender apenas a criar serviços relacionados ao respectivo model, e pelo visto, cada caso é um caso. Se for preciso, posso criar sim abstrações, especializações etc.
Te agradeço demais pela resposta!
>
54 minutos atrás, Dorian Neto disse:
[...]se eu deveria me prender apenas a criar serviços relacionados ao respectivo model, e pelo visto, cada caso é um caso[...]
Exatamente.
Se você for analisar os seguintes casos:
-
Banco de dados;
-
Entidades;
-
Modelos.
Um modelo (Model), pode possuir entidades (Entities). Entidades, por sua vez, podem estar persistidas em um banco de dados (Storage). Entretanto, isso não significa que pode existir apenas um modelo por entidade, uma entidade por tabela e/ou vice-versa. Isso é apenas comum por uma questão de "comodidade" e conhecimento. Visto o fato que é mais fácil desenvolver 1:1 quando se tem apenas esse conhecimento de desenvolvimento.
Depende muito da responsabilidade de cada um.
Se o processo de criar um usuário, independente do que ele seja, é uniforme, não há o porque de se criar um service para cada tipo de usuário. Afinal das contas, todos são usuários.
Entretanto, se isso envolve outras áreas do sistema, vale a pena mapear e procurar o que é específico de cada usuário e, assim então, criar uma especialização de cada usuário.
Além disso, existe o fato de que, ao criar um serviço abstrato e suas especializações, você fecha o conjunto de classes para modificações, mas abre para extensão (Open-closed principle). Mas deve-se perguntar a primeira pergunta, o usuário terá um comportamento completamente diferente, ou apenas o seu relacionamento com a role que determina seu comportamento. Se for apenas o relacionamento com a role, não há porque especializar cada usuário.
De qualquer forma, não conheço o cenário completo que você está trabalhando.