Regra de negócio nos Controladores?
23/10/2012 19:23
0
Comunidade, boa tarde.

É muuuuito errado colocar a regra de negócio nos controladores?

Não estou desenvolvendo nada corporativo, muito pelo contrário. O que tenho feito são pequenos testes para treinar os conceitos que tenho aprendido de groovy/grails/gorm...

Mas queria já me habituar desde o início a fazer a coisa certa...

... e lendo aqui no forum eu vi que regra de negócio é papel das classes de serviço. Isso é uma espécie de convenção? por que que melhor? organização do código e também desempenho?

Eu tenho me esforçado ao máximo (e tenho tido êxito na minha visão) em não misturar views com controllers.. (principalemente)

Devo já me converter a colocar as regras de negócio/validações em classes de serviço?

Obrigado
Tags: regra de negocio, controllers, services, rules, boas práticas


2
Eu acho bem errado em termos de boas práticas, perde mto a legibilidade do código.
Os serviços trabalham com transações, o que é uma vantagem.

Aconselho já ir trabalhando com serviços, é muito fácil se acostumar perpetuar as práticas por preguiça ehhehehe
23/10/2012 19:44


2
Fala Brother!

Concordo com o Mussatto, o melhor é se acostumando com as boas práticas! seu código vai ficar muito mais organizado! E seria uma boa idéia vc criar o hábito de escrever seus testes! Pq depois pra criar este hábito na correria vai ser complicado!
Acho uma boa idéia, quando tiver um tempo, se vc já domina! Estudar as tecnologias que estão por trás do Grails, para entender melhor como funciona e conseguir interpretar todo o conceito proposto pelo Grails!

Abraço!


0
Obrigado Mussato e Gabriel pela rápida resposta.

Tenho que mudar meus hábitos, mesmo... testes é outra coisa que não costumo fazer e preciso começar a mudar os conceitos.

É como o Henrique disse.. o Grails induz a gente a fazer a coisa certa, né.. cria os testes, organiza todas as estruturas de diretório "automaticamente"...

Eu não "domino" nada... na verdade eu acabo sabendo um pouco de tudo e muito de nada...

Se puder tiver alguns links quentes e puder compartilhar eu seria grato. Tenho me baseado muito em "how to's" somente.

Obrigado mais uma vez!

Abs!
23/10/2012 21:44


2
Sabe Rafael, eu vejo a coisa da seguinte maneira.

Em um primeiro momento, parece que é uma boa idéia você colocar sua lógica no controlador, afinal de contas, muitas vezes é apenas uma consultinha boba ou uma inclusão simples que por lá mesmo já se resolve o problema. O próprio código do scaffolding faz isto, sendo assim já serviria como um bom exemplo certo? Errado: é um péssimo exemplo.

O que acontece: quando pensamos no MVC, a idéia por trás do controlador é que ele sirva de intermediário entre a sua camada de visualização e negócio. E como intermediário, seu papel básico é apenas o de orquestrador, ou seja, pegar o que vêm da requisição, transformar caso necessário para parâmetros da camada de negócio e enviar o resultado (ou transformá-lo caso necessário) para a sua view.

O ideal é que o controlador seja o mais simples possível. Ele deve apenas fazer o que mencionei acima e no máximo escolher com base em alguma lógica o que será exposto para o usuário através de um redirecionamento ou escolha de visualização.

Bom: por que isto né? A razão é a seguinte: tudo em software gira em torno da qualidade. Quanto mais complexo for o seu controlador com sua lógica de negócio, mais difícil fica pra você manter seu código, pois o acoplamento neste trecho é maior: seu controlador além de precisar fazer o orquestramento de requisições agora também cuida do seu negócio. Separar os dois no futuro vai ser um inferno.

Outro problema: testabilidade. Testar controladores é fácil quando eles fazem o que tem de fazer. Começou a incluir lógica de negócio, o seu teste fica mais complicado de ser escrito: você difícilmente conseguirá escrever um teste unitário, por exemplo: todos terão de ser sempre integrados, e com isto vêm o custo de manter o teste, montar ambiente, etc. Quando sua lógica de negócio está no service, escrever o teste fica ordens de magnitude mais simples: você pode mocar objetos por exemplo com maior facilidade, pode isolar seu código melhor.

Isto sem mencionar que em serviços você ainda tem por padrõa o controle transacional PRONTO do Spring. No controlador fazer isto é bem mais difícil.


0
E olha que eu não falei ainda sobre o reaproveitamento hein? Difícilmente você reaproveita uma lógica escrita no controlador: mas fácilmente reapvoveita o que se encontra em um service, pois basta injetá-lo nos demais componentes do sistema.


0
Rafael, bom dia. Controlador tem sua própria lógica, que não é lógica de negócio mas aquela que orquestra a resposta à requisição com outros elementos da aplicação: visão, modelos, serviços. A lógica que eu vislumbro para o controlador é aquela que tem a ver com estado da apresentação: "mastigar" os dados recebidos pelo serviço e estruturá-los da forma mais direta possível para apresentação pela visão (de forma a diminuir código nas views).

Eu trabalhei pouco com Grails e agora tô num projeto que usa ASP.NET MVC 3, que tem ideias bastante semelhantes às de Grails quanto à estruturação de projeto, implementação de MVC, etc. Tenho me esforçado para deixar o máximo de lógica de negócio nos serviços sempre que escrevo código, e observado o código das outras pessoas da equipe para garantir que elas sigam essa orientação.

Um benefício excelente que o Henrique apontou muito bem é a testabilidade. :)

[]'s


0
"Difícilmente você reaproveita uma lógica escrita do controlador, mas facilmente reaproveita o que se encontra em um srevice, pois basta injetá-lo nos demais componentes do sistema"

Henrique,

Eu já tinha percebido a dificuldade e a consequente repetição de código em função do mal uso dos controladores, mas não tinha expandido minha cabeça em relação ao uso das classes de serviço. Obrigado pelas dicas e por compartilhar sua experiência.

Ontem eu estava lendo alguns fragmentos do "Groovy and Grails Recipes - Bashar Abdul" sobre a questão das classes de serviço "na prática" e ficou muito claro a questão da injeção desses serviços em outras classes e também tal "static transients" que eu não sabia exatamente o papel.. O negócio é demais.

Agradeço, mais uma vez pelo suporte de todos!

Abs!
24/10/2012 20:15



Ainda não faz parte da comunidade???

Para se registrar, clique aqui.


Aprenda Groovy e Grails com a Formação itexto!

Newsletter Semana Groovy

Assinar

Envie seu link!


Livro de Grails


/dev/All

Os melhores blogs de TI (e em português) em um único lugar!

 
Creative Commons
RSS Grails Brasil é mantido por itexto Consultoria.
Em caso de problemas contacte Henrique Lobo Weissmann (Kico) por e-mail: kico@itexto.com.br
Todo o conteúdo presente neste site adota o Creative Commons como licença padrão.
Ver: 4.14.0
itexto