none
Plano de senha - Em qual camada deve ser chamado RRS feed

  • Discussão Geral

  • Qual a melhor camada de uma aplicação para se implementar verificação de permissões de usuário?

    Nos casos de aplicação orientada a serviços e que usa repositório, a maioria dos blogs e sites que vi, sugere que esta validação não seja colocada em nenhuma destas camadas.

    Da até para entender aqueles que apoiam que isso não deve ser verificado no repositório, já que seu objetivo é persistir e consultar dados estando alienado às regras da aplicação, mas, não entendo por que isto não pode ser uma responsabilidade da camada de serviços.

    Como por exemplo:
    Quando vou chamar um processo que gera uma tabela de preços (método na camada de serviços) tenho que ver se o usuário que está fazendo a operação tem permissão para isto. Muitos aconselham que isto deve ser feito no client (Pelo menos quando se está usando MVC , é sugerido usar o atributo Authorize, inclusive criei um atributo meu que faz as minhas verificações de acordo com meu serviço de controle de acesso que está no projeto da minha camada de serviços).

    Mas enfim, não concordo que a chamada desta verificação deve ser feita lá, pois imagine alguma aplicação que deve ser migrada para windows form, quando alguém esquecer de fazer um "if(tem permissao de acesso)" na interface de usuário, o funcionamento lógico da aplicacação será alterado, levando em conta que de acordo com a lógica do meu aplicativo , usuários só podem gerar tabelas de preço se tiverem permissão para isto. E pensando da maneira com que sugerem que seja feito, a lógica de funcionamento do meu aplicativo está na UI. Isso quer dizer que se o fundo da minha tela for rosa, nenhuma permissão será verificada... rsrs

     

    O melhor lugar para se verificar permissões de acesso é a camada de serviços, o que vocês acham?


    +.+
    domingo, 9 de maio de 2010 04:03

Todas as Respostas

  • Acredito que a validação de permissão deva estar na camada de negócio, para que qualquer outra camada respeite essas restrições. O que acontece é que a interface deve de refletir as restrições de acesso de alguma maneira. No seu caso a classe "CONTROLLER" pode informar a interface as restrições de acesso de maneira que você possa esconder um botão ou opção de menu.

    Nas aplicações que desenvolvo mesmo um serviço que, por exemplo, rode uma rotina de faturamento tem que se autenticar para que possa acessar os métodos necessários para concluir a tarefa.

    domingo, 9 de maio de 2010 14:19
  • Se for uma validação muito complexa, eu utilizo um serviço e recomendo que seja. O serviço me retorna um objeto de autenticação q depois a interface vai fazer o que quiser com ele. Agora se é uma validação simples tipo, retornar usuario por email e senha, faço diretamente no repositório.

    Acho q se vc tiver um objeto de autenticação no Dominio, apenas com o repositório seja suficiente para fazer as verificações. Uma vez que nesta arquitetura prega-se que as regras de negócio estejam no Dominio.


    Quem sabe um dia os DataSets se extinguirão?
    segunda-feira, 10 de maio de 2010 19:14
  • é, também acho que refletir as permissões de acesso na camada de usuário é uma boa coisa... falando nisso, tem alguma dica de como fazer isso? Talvez um user control ou seilá... eu estava fazendo um esses tempo atrás, na verdade era uma classe que tinha informações do texto do menu, os menus filhos e o id da permissão.. a classe que renderizava isso usava o repositório para consultar todas as permissões(claro que tudo de uma vez) e ir dando loops e loops nesses itens e renderizando somente as permitidas. A minha única preocupação foi o consumo de processamento e etc, mas acho que um cache bem configurado já resolve.

    Alguém sugere outra forma de fazer?


    +.+
    quarta-feira, 12 de maio de 2010 02:02
  • Olá Davi,

    Bem sugiro dar uma estudada sobre WIF, veja uma referencia: http://www.israelaece.com/post/Explorando-o-WIF.aspx

     


    Abraço, Espero ter ajudado. Caso sim, marque-a como tal.
    sexta-feira, 14 de maio de 2010 02:32