Bom, estou estudando um projeto que trabalha com MVC da seguinte forma:
GUI (View) ---- se comunica com — > BO (Business Object).
O BO utiliza o Bean e também utiliza o DAO. Gostaria de saber porque usar BO em vez de Controller ?
É um objeto que recebe a lógica de negócio de uma classe.
Por exemplo: vc tem uma classe Conta, com apenas os atributos privados, e uma classe ContaLogica, com os métodos de negócio, como abrirConta(), fecharConta(), etc.
Caia fora disso, é uma gambiarra!
Mas não é a mesma função do Controller ? O controller é quem cuida da lógica de negócio.
Não, a lógica de negócio = domínio, ou seja: deve ser tratada dentro da classe em questão - ou qual seria a vantagem de ter objetos, então?
O que o controller tem como dever é cuidar do fluxo da aplicação.
Então tenho:
GUI (View) --> Controller --> DAO --> Bean
a lógica da aplicação fica onde ? DAo ?
o que é [quote]lógica da aplicação[/quote] pra vc?
Legal mas na prática o MODEL se divide : Temos os DAOs e os BEans (POJOS)
PS: Lógica da Aplicação = Lógica de Negócio, é onde fica aplicado de fato as regras de negócio.
POJOs são jurássicos, não são mais usados - nem aconselhados.
Isso cria os famosos “objetos anêmicos ou fantoches” - já que você estará usando a sua classe POJO apenas como uma espécie de estrutura de dados, deixando a lógica dela de fora.
Uma pergunta: sabe realmente a definição de POJO? E DAO?
POJO é o “espelho” da tabela no banco, são neles que fazemos o mapeamento JPA, por exemplo. Por outro lado o DAO é o responsável por realizar o CRUD, que é nele que creio ficar a lógica da aplicação. Me corrija se estiver errado.
POJO são Plain Old Java Objetcs, ou seja, classes java que apenas possuem atributos e métodos getters / setters. São utilizados geralmente pra isso, uso de frameworks. Se pesquisar um pouco mais vai ver que não é uma prática muito recomendada hoje em dia - logo posto um link de um pdf que mostra os porques.
Leia mais atentamente como funciona o MVC na imagem que postei - apesar dele ser quase utópico, pois o MVC que usamos na web é bem diferente deste.
Vamos voltar desde o começo a lógica é: o dominio da aplicação.
O que vai no controller, é o COMPORTAMENTO da aplicação - behavior, segundo a imagem postada antes.
Ate aqui tudo bem amigo, mas sendo um pouco mais prático, onde ficaria definido a lógica da aplicação se no VIEW fica a apresentação, no Controller fica o comportamento e no Model fica os POJOS.
Está justamente ai o problema: você está confundindo o que realmente é a lógica. Não existe lógica da aplicação, e sim lógica de domínio.
Se seu objeto precisa de alguma condição pra fazer uma operação, quem deve verificar se esta condição foi satisfeita é o próprio objeto. Isso não deve ser feito no controller, como acho que pensa.
A Única palavra “lógica” que você deve usar é para o objeto, e não para a aplicação. Para a aplicação há apenas um fluxo.
Se por lógica de aplicação você quer dizer as condições que devem ser satisfeitas quanto ao sistema, e não ao domínio, ai já é outro assunto.
e as regras de negócio, não são a parte principal da aplicação ? onde elas entram nesse contexto?
Regras de negócio e lógica de negócio são o mesmo.
Fica na classe - MODEL.
Legal fica no MODEL, e o que temos no MODEL ?
Falando em termos práticos: POJO + DAO. Em qual desses ficará a logica ?
Mas então, $erver, podemos esquecer o DAO e usar o active record em seu lugar, não? Afinal, se os POJOs não são mais boas práticas, o DAO é obsoleto também. Assim deixamos todas as responsabilidades com os objetos e não nos preocupamos com outras camadas.
Oi drsmachado, que bom vc por aqui, admiro muito o seu conhecimento.
Então active record, se não me falha a memória, é fazer a persistência no próprio objeto?
rlanhellas,
Por favor, esqueça a palavra POJO. Pense na classe e suas responsabilidades - pois é disso que trata o MVC, divisão de responsabilidades.
No MODEL - sua classe - temos os atributos e os métodos que fazem operações sobre eles. representando assim um objeto do mundo real. Uma pessoa não tem somente o atributo nome, mas também fala, anda, paga contas, etc … Então esses métodos precisam estar na classe.