12/03/2009 10:37:01 Assunto: Re:Opinião - Abordagem MVC
ismaelrg wrote:Oi Wagner, segue:
Opa. Em termos de MVC (ou melhor, daquele MVC 2) acho que não tem nada errado. Talvez fosse interessante você mudar um pouco a estrutura das classes.
Você tem um Servlet que faz tudo, mas como você vai tratar as requisições dentro dele para chamar os componentes do Model? Através de ifs? Talvez, se você fosse fazer assim, seja interessante utilizar diferentes Servlets pra diferentes ações.
>> Não terei um único servlet não, terei vários para chamar os componentes do Model e será com "ifds" mesmo.
Se você tiver vários servlets nem vai precisar desses ifs mesmo! O melhor é evitar cadeias longas de if.
>> OK
ismaelrg wrote:
Uma coisa que achei confusa é que você chamou UsuariosMD de Model e falou que o model valida os dados. Tudo bem, UsuariosMD também faz parte do Model nesse caso, mas o interessante é que a própria entidade (Usuario) se mantenha consistente (na medida do possível). UsuariosMD parece mais uma coleção de usuários, ela não deveria conhecer como funciona a entidade Usuário internamente.
>> A idéia que pensei aqui era a seguinte: UsuáriosMD é uma classe de negócios. Ela possui métodos como Login(), Logoff(), Inativar(), Ativar(). Essa classe valida os dados de acordo com minhas regras de negócio e a partir dela, caso seja necessário persistir algum dado para a base de dados, ela acessaria o UsuariosDAO.
Tipo, se nessa mesma classe você está armazenando instâncias (como comentou anteriormente com incluirUsuarios()), fazendo logon, ativando e inativando usuários e fazendo tudo, essa classe tem diversas funcionalidades. Isso não é bom (fere o princípio da responsabilidade única). Será que precisa ser tudo aí? Você não pode ter uma classe por exemplo que represente o serviço de login? Você tem uma entidade Usuario no sistema? Ela tem comportamento?
>> Na verdade Wagner, ainda não está modelado, portanto ainda não tenho a entidade Usuario. Tudo que disse é uma hipótese para construir um sistema. No caso então, vocÊ aconselha a ter classes que representem os serviços por exemplo, como login, logout, inativar, ativar. Seria isso ?
ismaelrg wrote:
Será mesmo necessário esse UsuarioBean? Você não poderia utilizar o próprio Usuario?
>> A idéia do Bean é ter um objeto serializável para ser transportados entre as camadas. Os dados recuperados da base de dados através da classe de negócios UsuariosMD são inseridos nesse UsuarioBean, para que a view faça uso dele.
O problema de usar esse UsuarioBean é que você tem objetos anêmicos assim. Não é interessante em sistemas Orientados a Objetos manter objetos anêmicos. Não é por isso que o sistema é ruim, mas parece que nesse caso você não precisa deles. Veja aqui:
http://www.fragmental.com.br/wiki/index.php/Evitando_VOs_e_BOs
[b]>> Entendi. Achei interessante esse post, que fala extamente sobre a necessidade dos VOs (ou TO). Veja aqui: http://markmail.org/message/qwt2aogobmublgyw#query:comportamento%20entidades%20java+page:1+mid:zgrff6kd5nftlv2v+state:results
[/b]
ismaelrg wrote:
Outra coisa, algumas literaturas sugerem que você não acesse a camada de persistência diretamente de dentro da tua camada de domínio, o padrão Repository (Domain Driven Design) poderia evitar isso se você achar conveniente.
>> Vou procurar sobre esse padrão.
Beleza. Domain Driven Design é o nome do livro, o autor é Eric Evans. Tem um resumo gratuito do livro que inclui explicações a respeito desse padrão.
ismaelrg wrote:
Abraço! Aguarde opiniões de outras pessoas.
>> Obrigado pela opinião. Uma outra coisa que não deixei claro: a camada de negócio (no caso do exemplo UsuariosMD) não interage com as Servlets API. Os dados são passados para ela de modo limpo.
Da forma como imaginei: acredito que não teria problema em migrar por exemplo a aplicação para desktop. Para isso precisaria reescrever os controllers e as view. Estou correto ?
Obrigado.
Sim, pelo que entendi você conseguiu isolar o Model. Você realmente tem um modelo MVC (um pouco alterado porque o Model não notifica View explicitamente, mas em aplicações Web isso é comum) e poderia alterar o componente View sem muitos problemas.
Falou!
[b]>> Obrigado por enquanto Wagner, sua opinião está sendo de grande valia.
Dentro da arquitetura que imaginei, pelo que entendi, você sugere criar classes managers, seria isso ?!? Ex: uma classe que por exemplo implementa o serviço de login, uma que implemente o serviço de inativação do usuário, etc. Essas classes interagiriam com objetos da entidade (usuarios no caso). Seria isso ? E no caso, quando houver por exemplo a necessidade de autenticar um usuário, o controller acionaria essas classes, seria isso ?!?! E então nesse exemplo a entidade usuario não teria comportamento ???!!! [/b]