[Duvida] PureMVC e Design de Orientação a Objetos

Assuntos Gerais
#1

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?

#2

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.

#3