ou existe a alternativa de voce fazer um modulo a parte cadastrando as telas e os acessos para cada usuario. Desta forma ficaria muito mais dinamico caso surja mais algum tipo de papel para usuário.
Luiz_Gustavo
Olá,
se me permite dar umas sugestões, você poderia colocar Usuario como a classe inicial da hierarquia, afinal, um Administrador e um Funcionário são Usuários do sistema, e os termos ficam mais próximos do domínio (AbstractUser é um termo que não existe no domínio).
Eu tenho feito assim nos sistemas. Por exemplo, tenho um sistema em que existem níveis de acesso como Educador, Administrador, Gerente, Consultor… todos eles são usuários, herdando de uma classe comum Usuario.
Essa classe tem atributos como nome, login, senha… que no fim das contas, quando refletido no banco de dados, me dará as informações para encontrar as credenciais, em uma autenticação que utiliza autenticação declarativa do Tomcat, por exemplo.
Espero tere ajudado.
Abraços!
danielbussade
Lógico, estou querendo é sugestões mesmo.
Interessante esta maneira de implementar, entao neste caso seu Usuario é uma classe abstract ? Ai quando tiver alguma classe que tem por composição um Usuário você faz a associação com a classe Usuario e nao com nenhuma filha dela, podendo este usuario ser qualquer um.
Valeu
rissato
geralmente eu uso JAAS, e todo o controle de acesso fica por conta de 1 tabela no banco e de algumas configurações no web.xml. Dá uma olhada nisso, assim vc não precisa preocupar com segurança em outras partes do sistema.
Emerson_Macedo
Muita gente controla acesso em sistemas web usando ACLs ou alguma implementação de RBAC. ACL dá pra implementar fácil na mão e é relativamente mais simples, mas vai depender se atende seu caso. Pelo que você descreve, está mais pra RBAC.
faelcavalcanti
mal percebi que existia uma implementação de java para representar estruturalmente uma lista de controle de acesso, Acl. Só não sei se foi a partir do java SE 5.0.
para o caso do modelo RBAC, o JAAS, acho que possui implementação para algum tipo de modelo. fiquei curioso agora.
1. gostaria de saber porque ele tem tido bastante aceitação?
2. para qual implementação também, caso tenha sido ?
3. caso tenham boas referência nos repassem!
para controle de acesso utilizei o acegi.
fabio.nascimento
Bom…
Só uma coisa, no seu caso não seria melhor usar composição em vez de herança?
Vai pensando aí…
Abraços.
danielbussade
fabio.nascimento:
Bom…
Só uma coisa, no seu caso não seria melhor usar composição em vez de herança?
Vai pensando aí…
Abraços.
Olá eu até pensei em usar composição até porque na verdade eu tenho tbm as classes ClienteFisico e ClienteJurídico que são usuários do sistema, então acho que fazer tudo herdar de usuario é um overkill. Pensei em fazer assim:
Desta forma se amanha eu precisasse de outro cliente no sistema faria ele implementar a interface Clienta tbm.
O que acham desta abordagem??
Obrigado
faelcavalcanti
acho melhor o cliente ter um usuario, assim como um funcionario o teria.
danielbussade
Pode ser tbm, mas se pensarmos bem um cliente é um usuário tbm , acho que aqui a relação pe de herança e nao de composição.
O que acha?
danielbussade
O problema de Usuario tem Cliente ou Cliente tem Usuario e como tenho outras classes que sao usuários ex:
Adm, e Funcionario fica estranho a relacao de que Adm tem Cliente ou Cliente tem Adm,entende?
Acho que a relação aqui e de Herança mesmo Cliente extends Usuario.
Valeu
faelcavalcanti
eu usaria herança em último caso, quando você não tem saída.
Você talvez poderia usar o padrão Strategy dependendo da quantidade de Entidades envolvidas neste relacionamento, de forma a definir também seu comportamento e características.