Estou começando a desenvolver com java e OO, então tenho algumas ( talvez muitas ) dúvidas ainda, talvez primárias, ou não.
É o seguinte.
Estou usando MVC. Até aí tudo bem, já entendi bem como funciona e tal.
Só que me surgiu uma dúvida. Eu posso ter uma camada entre o Controller e o Model ?
Aonde eu vou escrever minhas regras de negócio ? No Controller ?
Eu poderia criar uma camada a mais, tipo ClienteManager, responsável pela regra ?
Salve…Seguinte, da uma lida na apostila FJ21 da Caelum, na parte de DAO(Data Access Object)…tu vai sacar a parada.
To começando agora tbm a usar esse esquema, e essa apostila me ajudou bastante.
To fazendo assim:
classetela - view
classebean - model
classedao - controller
Existe um modelo chamado de MVC-2 que há sim uma camada a mais, exatamente a Manager que vc refere. Então pode usar sim, crie uma camada a mais e coloque tuas regras de negócio lá.
wikipedia: Model-view-controller (MVC) é um padrão de arquitetura de software que visa a separar a lógica de negócio da lógica de apresentação, permitindo o desenvolvimento, teste e manutenção isolado de ambos.
o interessante eh usar o controller para a regra de negocios, nao necessariamente dentro do DAO, mas fazendo uma modelagem na qual principalmente a view esteja separada, só chamando os metodos e etc das outras camadas… dá mais trabalho mas vale muito a pena
acredito que o ClienteManager que voce citou faz muito sentido usar sim, por exemplo nele vc pode guardar um array de Clientes (MODEL) e apresentá-los numa view (ex: TelaClientes)… claro que usando java web voce tem frameworks que te ajudam melhor nisso…
Quando eu tenho alguma lógica que vai trabalhar com duas ou mais entidades (models), crio uma classe Service (ou qualquer outro nome), que vai conter essa lógica específica.
[quote=bglbruno]Hm, legal !
Gostei dessa ideia da classe Service j0nny. Mas, seria a mesma coisa que uma Manager? Ou eu teria as duas?
Valeu Pessoal ![/quote]
Acho que não precisaria da Manager tbm, ou crie somente a Manager, o nome, nesse caso, não importa muito, desde que esteje claro para sua equipe qual o papel dessa classe.
Eu tenho a view, que vai conversar direto com o controller.
Então o controller conversa com o Manager / Service, executa toda a regra. E Depois ?
Quem deveria conversar com o DAO / Repository ?
Eu tenho a view, que vai conversar direto com o controller.
Então o controller conversa com o Manager / Service, executa toda a regra. E Depois ?
Quem deveria conversar com o DAO / Repository ?[/quote]
Controller conversa com seu Service (caso tenha, muito cuidado para não criar Services que apenas delegam funções para alguém), que faz alguma lógica nas suas entidades e persiste (caso precise) usando um Repository ou um DAO.
Eu costumo usar da seguinte maneira:
Controller (Activity quando estou programando para Android) -> Service (caso precise, caso contrário pule essa camada) -> Repository
Repository prefiro que seja apenas uma interface com as operações que devem ser realizadas, ee meu DAO implementa essa interface.
Nesse caso minhas lógicas não sabem da existência de um DAO ou algo parecido.
Mas como falei, muito cuidado com classes que apenas delegam funções.
Como assim as lógicas não sabem da existência de um DAO ?
Na classe Service você não vai precisar receber um DAO no construtor ?
E nos métodos eu faria assim, certo ?
public void regraAdicionar(Cliente c){
/* ... regra para adicionar ... */
this.dao.adiciona(c);
}
[quote=bglbruno][quote=j0nny]
Repository prefiro que seja apenas uma interface com as operações que devem ser realizadas, ee meu DAO implementa essa interface.
Nesse caso minhas lógicas não sabem da existência de um DAO ou algo parecido.
[/quote]
Certo !
Só não ficou claro uma coisa.
Como assim as lógicas não sabem da existência de um DAO ?
Na classe Service você não vai precisar receber um DAO no construtor ?
E nos métodos eu faria assim, certo ?
public void regraAdicionar(Cliente c){
/* ... regra para adicionar ... */
this.dao.adiciona(c);
}
[/quote]
Nesse caso que passei pra vc, o DAO implementaria o Repository, então o Service receberia o Repository no construtor, e não o DAO.
Saquei!
Uma outra dúvida que tenho quanto ao repository.
Ele conversa com a base de dados também ? ou somente por meio do DAO ?
Acho que o DAO deveria ficar responsável pelo CRUD basico
E o Repository delegar operações CRUD pro DAO, e outras lógicas além do CRUD, o Repositoty ficar responsável.
Ai o Service não saberia da existência mesmo do DAO, por que o usa é o Repository
[quote=bglbruno]Saquei!
Uma outra dúvida que tenho quanto ao repository.
Ele conversa com a base de dados também ? ou somente por meio do DAO ?
Acho que o DAO deveria ficar responsável pelo CRUD basico
E o Repository delegar operações CRUD pro DAO, e outras lógicas além do CRUD, o Repositoty ficar responsável.
Ai o Service não saberia da existência mesmo do DAO, por que o usa é o Repository
Seria essa a estrutura ?
[/quote]
Exatamente, o Repository faz a frente das operações, mas quem se responsabiliza mesmo com elas é o DAO.
O Repository não fica responsável por nada além de fazer frente as operações de banco, etc, pq ele é uma interface, e não uma classe.