Design do Controller , qual a melhor abordagem?
15/05/2012 11:21
0
Olá a todos,
Utilizo Grails há algum tempo em meus projetos e freqüentemente ficou em dúvida sobre qual a melhor arquitetura para os controllers.
Atualmente, coloco toda a lógica em services e, caso ocorra algum problema, disparo uma excessão a ser capturada pela action. Segue exemplo:
Essa é uma boa abordagem? Quais vocês utilizam?
Obrigado.
Utilizo Grails há algum tempo em meus projetos e freqüentemente ficou em dúvida sobre qual a melhor arquitetura para os controllers.
Atualmente, coloco toda a lógica em services e, caso ocorra algum problema, disparo uma excessão a ser capturada pela action. Segue exemplo:
class ClassController {
def action {
try {
classService.doSomeProcess()
} catch(Exception e) {
//tratamento
}
}
}
class ClassService {
void doSomeProcess(){
//process
if(error){
throw Exception()
}
}
}
Essa é uma boa abordagem? Quais vocês utilizam?
Obrigado.
0
Olá, Bruno.
Amigo, sou fã do princípio KISS. Logo, acredito que todo erro deva ser tratado da mesma maneira, com raras exceções.
Eu gosto da seguinte abordagem:
Para erros "não previstos":
Que tal simplesmente não fazer os erros te levarem para a página de erro padrão do sistema (estilo google, yahoo e afins)? Dai você escreve o erro em log, manda email, enfim, qualquer coisa que te ajude a saber que os erros estão havendo.
Para erros "previstos" (relacionados às regras de negócios):
Ai sim usaria "try/catch", adicionando mensagem ao "flash" e exibindo na view.
Amigo, sou fã do princípio KISS. Logo, acredito que todo erro deva ser tratado da mesma maneira, com raras exceções.
Eu gosto da seguinte abordagem:
Para erros "não previstos":
Que tal simplesmente não fazer os erros te levarem para a página de erro padrão do sistema (estilo google, yahoo e afins)? Dai você escreve o erro em log, manda email, enfim, qualquer coisa que te ajude a saber que os erros estão havendo.
Para erros "previstos" (relacionados às regras de negócios):
Ai sim usaria "try/catch", adicionando mensagem ao "flash" e exibindo na view.
15/05/2012 12:05
0
Obrigado pela resposta.
Com base na sua proposta, vou rever algumas das excessões enviadas ao usuário, ja que muitas não podem ser resolvidas com preenchimento de formulários...
Além do tratamento de erros, você também transfere todo o processamento das actions para services ou faz tudo dentro da própria action mesmo?
Com base na sua proposta, vou rever algumas das excessões enviadas ao usuário, ja que muitas não podem ser resolvidas com preenchimento de formulários...
Além do tratamento de erros, você também transfere todo o processamento das actions para services ou faz tudo dentro da própria action mesmo?
15/05/2012 14:04
0
Se usa-se Services, só se deve tratar nos Controllers aquilo que impede o uso dos próprios Services. Exemplo: a não chegada de um parâmetro de requisição esperado.
15/05/2012 16:40
0
Esta modelagem adotada, a implementação das actions dos controllers em services, trata-se de um simples padrão de modelagem adotada, ou existe algum reflexo no desempenho ou outra característica do software final?
[]'s
[]'s
23/05/2012 13: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
Os melhores blogs de TI (e em português) em um único lugar!
