Olá pessoal,
minha dúvida é mais em conceitos de arquitetura e transições dos objetos num contexto Flex (PureMVC) com BlazeDS + Java
como muitos sabem, o BlazeDS torna possível chamadas ActionScript na camada Java por meio de um remoting-service, mapeando classes Java, afim de chamar os métodos contigos nessa remotamente.
A partir desse principio, tenho a seguinte situacao:
um numero x de classes de serviço Java, que se comportam como Façades para os controladores (ActionScript) da camada de apresentação, ou seja, são as classes mapeadas no remoting-service.
Se eu quiser consultar ou consolidar algum dado que o usuário digitou na tela por exemplo, acontece o seguinte:
[APRESENTACAO] -> *Controlador-Mediator->Proxy->Delegate -> Servico -> DAO -> DB
*Padrão de patterns seguido pelo PureMVC
Finalmente, minha duvida e problema. Ficou claro que minha classe de Serviço está efetuando regras de negócio e também tendo métodos parecidos do DAO, e apenas repassando a bola pra ele. Futuramente essas classes ficariam irreconheciveis nao? Quebrando o principio de responsabilidade unica (SRP).
Alguém já passou por algo similar? Quais as recomendacoes?
No caso a sua dúlvida e a seração da camadas de sua Aplicação usando tambem o MVC.
Na SRP ela define que é necessário separ as obrigações e que uma classe deve possuir apenas 1
obrigação/responsabilidade. Então é uma questão de Análise da sua Aplicação…
Como você esta sequindo esse PureMVC , ele te ajuda a separar os bois, mas sempre se pergunte: Isso deve ficar numa classe
de Serviço ou DAO ou Visão ?? E uma boa pratica…
Eu divido assim:
- Action
Que são as classes que recebem a resquisição, elas trabalham com apenas envio e recebimento de dados, nenhuma
lógica deve estar nessa classe, ela irá repassar o Controle para o Service, atuando como um Business Delegate, e essa é uma camada que pode ter algum acoplamento com o framework seja ele struts, vraptor, mentawai… pois você pode aproveitar os recursos do Framework.
-
Service
Esse é o cara, você deve projetar essa Camada para não ter nenhum tipo de acoplamento
nem com o banco de dados, nem com nunhum framework específico. Para isso você deve usar o Conceito
"Use interfaces ao invês de implementações" voce pode ter um PessoaService(interface) e PessoaServiceHibernate (implementação), caso você querira precise mudar de framework apenas implemente PessoaServiceFrameworkX, e
procure usar IoC (Iversão de Controle) isso ajuda a diminuir o acoplamento
-
Modelo (Os Velhos POJOs)
-
Dao - Eu tenho os daos somente com operações de CRUD, se precisar implementar uma busca de pessoas
com fiversos critérios: nome, cidade, estado, essa implementação é feita no Service (pois de certa forma é uma
regra de negócio) pois se o Cliente quiser um novo critério de busca, ou seja , mudou a regra de négócio…
as alterações teriam que ser na camada de negócio não nos DAOs.
Bem isso é um dos modelos que existe e que EU sigo, existem vários, cabe a você testa-los e ver o que mais se adequa a sua
realidade.