Olá pessoal,
Estamos migrando uma grande aplicação para Java e uma das coisas que me chamou mais atenção nela é que as regras/controles de acesso estão impregnadas por todo código (que é procedural). E elas são muitas, complexas e frequentes.
Estou tentando abstrair isso para que o código de negócio fique o menos poluído possível, e pensei se orientação a aspectos não me ajudaria.
A aplicação não é WEB e tenho regras do tipo:
IF campoTal é AB ou CD ou EF
Peça autorização de um gerente
Ou
Execute uma proc, se ela retornar X ou P ou T, peça autorização do Gerente.
Ou
Se a transação for X e o nível de acesso do usuário for <= 5, mostre tal mensagem.
Ou ainda, se uma combinação desses tipos.
Níveis de acesso também são utilizados para permitir acesso a determinada tela, mostrar campos…
Queria isolar essas coisas, de maneira que o código de negócio ficasse separado.
Alguém tem exemplos de como obter esse desacoplamento?
OBS: Não sei ao certo quanto dessas regras não fazem mesmo parte das regras de negócio, mas queria pelo menos ter uma idéia do que e como usar caso consiga abstrair pradrões de acesso.
Obrigado
Sim… orientação a aspectos poderia te ajudar…
MAS… vc consegue fazer a mesma arquitetura de orientaçao a aspectos numa aplicacao só com orientacao a objetos… pode até ser um pouco complicado. mas consegue
Voce tem que ter os seguintes cuidados ao usar aspectos… primeiro se a equipe que desenvolverá o sistema conseguirá entender… e alguém superior vai aceitar (sempre tem esse alguém nas empresas)
Segundo, tem que tomar um cuidado gigantesco para nao virar bagunça o projeto… pq pode chegar um desavisado que usará aspecto para qualquer problema do sistema
Se vc nao está conseguindo montar esses problemas usando OO. recomendo estudar bem padrões de projetos… mas nao é pra decorar nao… é enteder… o que pode ser bem complexo…
E na sua arquitetura… sempre deixe espaço para na pior das hipóteses… o cara fazer um if na mao… o ideal nao é fazer o if… mas é necessário ter esse espaço…
Também é importante que seja mais fácil definir as regras usando uma maneira bonita… do que usando um if no código… se nao… em pouco tempo o povo abandona a arquitetura e passa a fazer ifs…
Bom trabalho 
Concordo com o amigo acima em genero numero e grau, a orientacao a aspectos é ótima para se implementar segurança e logs, mas é necessário medir o grau de maturidade da equipe para utilizar essa tecnologia. Se não, o que era uma grande idéia acaba virando um grande problema. A melhor tecnologia é aquela que vc conhece melhor.
Só mais um adendo, eu estou achando que tem misturado com o que vc comentou, regras de negócio, que até utilizam características de segurança como contexto, mas que não tem muito muito haver com acesso propriamente dito.
Eu usuaria algo pronto para autenticação + autorização (SpringSecurity da vida) e deixaria essas regras de negócio específicas em cada objeto, citando algo do seu post : Se a transação for X e o nível acesso <= 5 mostre a mensagem, Tente realmente separar o que é de responsabilidade de cada um. Se estiver empolgado, vc pode criar uma DSL para trabalhar junto com o framework de autenticação + autorização, pode ficar interessante… dê uma procurada sobre interfaces fluentes caso vc queira ir para esse lado de DSL…
[]'s
Só pra complementar o que o colega rogelgarcia falou: caso não queira usar aspectos, o padrão Proxy pode resolver o seu problema também.
