Business Object VS Controller

Programação Arquitetura
#61

Sei não, fiquei na dúvida nisso agora também. Vou fazer uma pesquisa amanhã, agora indo pra casa. Muito obrigado, e até amanhã! Abraços![/quote]

Legal… também vou fazer uma pesquisa e tentamos chegar nessa conclusão, pois posso também estar errado!
Abs[/quote]

Algumas pesquisas rapidas e temos diversas opniões iguais a minha (e acredito que baseadas no que o Fowler definiu)…
POJO não é Javabean, mas todo Javabean é POJO

http://www.guj.com.br/java/53305-conceitos-javabeans-pojo-vo-e-dto


http://docstore.mik.ua/orelly/java-ent/jnut/ch06_02.htm

[/quote]
Discordamos, portanto.
Um POJO, como definido por Fowler, pode ser um JavaBean. Porém, como o POJO poderá ter métodos diferentes do que a especificação JavaBean define, nem todo JavaBean pode ser um POJO. [/quote]

…pojo nao eh javabean, mas pode ser como vc falou… Falamos a mesma coisa com palavras diferentes. Mas Nem todo pojo eh javabean e dependendo nem todo javabean eh pojo… Esta correto realmente. Conclusao, pojo nao eh classe cheia de getters e setters…mas tbem pode ser…

e ah, alem de javabean temos os dtos e vos tbem…

#62

[quote=DiegoPessoa]$SERVER, confesso que fiquei um pouco confuso com o seu ponto de vista. Primeiramente você diz que utilizar os JavaBeans na camada de modelo (classes que contem os atributos espelhando o que está no banco de dados) é uma prática ultrapassada, porém, logo após você se contradiz, dizendo que realmente não daria para agregar a uma simples classe de entidade todas as responsabilidades de gerenciamento de conexão, transações. Sendo assim, não seria nem uma coisa nem outra? :stuck_out_tongue:

A meu ver, isso de “Usar JavaBean está ultrapassado” não procede. Com que base você afirma isso? Considerando um projeto com ORM, utilizando por exemplo Hibernate, temos uma distribuição ideal de responsabilidades em que a “Entidade” (JavaBean) contém os atributos, os respectivos mapeamentos e também algumas named queries, que de certa forma fazem o papel do active record para busca/leitura, mas na minha opinião seria inviável adicionar métodos salvar, atualizar, remover, numa entidade em um projeto com essas características.
Em contrapartida, a utilização do DAO ou não ainda divide opiniões, visto que o próprio framework de persistência oferece uma implementação do EntityManager, que de certa forma já funciona como um DAO genérico. Sendo assim, pra mim, os DAO são totalmente dispensáveis, eu costumo trabalhar com um DAO genérico que é acessado diretamente pelos objetos de negócio (SessionBeans EJB). Para não ficar um acoplamento tão grande em relação a tecnologia (SessionBeans injetando diretamente o EntityManager), pode ser criado um SessionBean que será o DAO genérico e irá injetar dentro dele o EntityManager, assim caso você queira trocar a estratégia de persistência, bastaria trocar a implementação do DAO genérico.
Outra coisa, sobre a divisão de pacotes, citada pelo nosso amigo rlanhellas. Eu não sou muito fã de dividir pacotes dessa forma, especificando “dao”, “bean”, “bo” etc. Imagina só um sistema com 100 entidades e 150 BOs. Você vai ter uma infinidade de classes dentro de um mesmo pacote. O que eu costumo usar é separar por módulos, que conversam entre si através de interfaces. Por exemplo: módulo de autenticação tem pacotes com suas entidades e BOs, módulo de gerenciamento de pedidos, módulo de gerenciamento de produtos, etc, etc. Quanto mais você dividir e componentizar sua aplicação, melhor. Então nesse caso, a dica que eu dou é: evite os pacotes genéricos demais. A nao ser que a aplicação seja extremamente pequena e focada.

A divisão de camadas que costumo usar é, por exemplo:

Módulo Corporativo (EJB):
Interface para fachada do módulo da aplicação > [implementado por] >> Session Bean que disponibiliza os prncipais métodos para o módulo > [utiliza] >> Classes de Negócio (Sessionbeans EJB) >>> utiliza >>> Interface de gerenciamento de persistência >> [implementado por] >> Session Bean que utiliza o EntityManager >>>[manipula] >>> Entidades (JavaBeans)

Módulo Web - interface gráfica:
Páginas XHTML >>> [acessam] >>> JSF Managed Beans >>> [acessam] >>> Interface para fachada do módulo da aplicação

Então, como se pode ver, MVC não é separar a aplicação em tres pacotes (model, controller e view) e jogar tudo de qualquer jeito lá dentro. Mas sim, a forma como você organiza a responsabilidade dos seus componentes, independentemente dos pacotes em que eles estejam.

[/quote]

Amigo, voce esta certo tbem… nao eh pq usamos java que temos sempre que optar por domain driven design ou usa todos conceitos oo. Penso que uma boa arquitetura ou padrao consiste em analisar uma serie de fatores da aplicacao a ser desenvolvida. Geralmente ha boas praticas a serem seguidas mas podem haver situacoes onde usr estas nao seja uma boa.
o importante eh definir um padrao e seguir este do comeco ao fim. Nao ha nada pior que aplicacao sem padrao com pagina abrindo conexao com o bando de dados.

#63

Particularmente eu parto do princípio de resolver o problema. A partir do momento que você fez o que tinha que fazer, o como é deixado de lado. Com o tempo você vai aprendendo a melhorar a construção do código. Porém, isso não implica em colocar tudo o que você sabe.
Penso em programação como música. Um acorde diminuto com sétima e nona pode soar bem bonito, mas não precisa ser colocado em todas as canções. Às vezes, as músicas com arranjo mais simples são as mais legais.
Programação é assim.

#64

Vários assuntos estão sendo discutidos no tópico e, a meu ver, é importante entende-los em separado para depois poder relacionar os conceitos.

A dúvida inicial era por que usar um BO ao invés de um controller. Ou ainda, por que não jogar a lógica de negócio da aplicação no controller. Pois bem, isto viola o princípio básico do MVC, que é justamente separar o domínio da aplicação da sua representação gráfica. Neste ponto, não estamos falando de BO, VO, DAO, nada do gênero. O objetivo aqui é simplesmente não ter objetos que misturam a apresentação gráfica com a lógica de negócio da aplicação. MVC possibilita este desacoplamento.

Isto não significa que todo o negócio vai ficar em classes BOs ou em entidades. Falou-se em DDD, mas antes de falar em DDD, eu acho que isto é uma questão genérica de separação em camadas. Ora, cria-se uma camada de domínio e todos os objetos que estão relacionados ao domínio estão nesta camada, sejam entidades ou não. DDD apresenta isto de maneira detalhada e, ao ler o livro fica claro que não existem apenas entidades. Outros padrões são apresentados: objetos de valor, repositórios, serviços, etc. Tudo isto na camada de domínio.

Falou-se ainda em pojo, e eu concordo com a definição do jmmenezes. Os POJOs como o próprio nome sugere, são objetos simples. Que não dependem de objetos de um container, framework, etc. Em geral, atualmente busca-se a utilização de POJOs não apenas na camada de domínio, mas nas outras camadas também. Hoje, por exemplo, muitos frameworks MVC têm controladores anotados ou configurados por convenção, pra não te forçar a estender uma classe do framework.

Por fim, sempre fica uma interrogação em como juntar estes conceitos e criar uma aplicação real. Eu vejo isto de maneira bastante simples: para o MVC, você possivelmente usa um framework. Ao invés de entupir a lógica da aplicação nos controladores, crie uma camada que contém esta lógica e apenas chame os serviços/facades desta camada a partir do seu controlador. Em ambiente não web, recursos de binding facilitam muito a aplicação do padrão MVC.

#65

diego, nao sou apenas eu quem diz que javabeans sao ultrapassados, o proprio fowler tmb desaconselha - vou ver se acho onde li isso. imagine uma classe sua onde vc deve realizar uma operacao com um atributo dela, e nao se pode atribuir valor algum a esse atributo fora do metodo q faz a tal operacao. dai vc precisa de um setter - pra orm ou msm di, como no caso do spring. no pior dos casos, a sua regra - nao poder acessar seu atributo fora do metodo nao setter - vai ser violada, e caso algum outro programador de manutencao em seu codigo um dia, podera comecar a usar o setter no controller em vez do metodo correto. ha um link de um pdf q postei la pra tras, de uma lida quando puder caso fique alguma duvida. desculpe os erros de portugues, celular com teclado virtual do android nao presta - ao.menos o lg optimus p500. abraco.

#66

discordo…pouco do.drsmachado, pra mim o como deve ser aalisado o tempo todo. acho q a oo tem todas essas regras nao pra deixar o codigo apenas mais bonito, mas pra q ele seja o mais simples e facil de entender por outro programador.

#67

boa noite vagner. entao, no inicio, nosso amigo perguntava se a logica de negocio.ia.no controller. a reaposta eh nao, mas se ele fizesse isso, estaria separando a logica da interface grafica, mas msm assim estaria errado.

#68

vagner, a logica da aplicacao q vc se refere eh diferente das regras de negocio, neh?

#69

[quote=DiegoPessoa]$SERVER, confesso que fiquei um pouco confuso com o seu ponto de vista. Primeiramente você diz que utilizar os JavaBeans na camada de modelo (classes que contem os atributos espelhando o que está no banco de dados) é uma prática ultrapassada, porém, logo após você se contradiz, dizendo que realmente não daria para agregar a uma simples classe de entidade todas as responsabilidades de gerenciamento de conexão, transações. Sendo assim, não seria nem uma coisa nem outra? :stuck_out_tongue:

A meu ver, isso de “Usar JavaBean está ultrapassado” não procede. Com que base você afirma isso? Considerando um projeto com ORM, utilizando por exemplo Hibernate, temos uma distribuição ideal de responsabilidades em que a “Entidade” (JavaBean) contém os atributos, os respectivos mapeamentos e também algumas named queries, que de certa forma fazem o papel do active record para busca/leitura, mas na minha opinião seria inviável adicionar métodos salvar, atualizar, remover, numa entidade em um projeto com essas características.
Em contrapartida, a utilização do DAO ou não ainda divide opiniões, visto que o próprio framework de persistência oferece uma implementação do EntityManager, que de certa forma já funciona como um DAO genérico. Sendo assim, pra mim, os DAO são totalmente dispensáveis, eu costumo trabalhar com um DAO genérico que é acessado diretamente pelos objetos de negócio (SessionBeans EJB). Para não ficar um acoplamento tão grande em relação a tecnologia (SessionBeans injetando diretamente o EntityManager), pode ser criado um SessionBean que será o DAO genérico e irá injetar dentro dele o EntityManager, assim caso você queira trocar a estratégia de persistência, bastaria trocar a implementação do DAO genérico.
Outra coisa, sobre a divisão de pacotes, citada pelo nosso amigo rlanhellas. Eu não sou muito fã de dividir pacotes dessa forma, especificando “dao”, “bean”, “bo” etc. Imagina só um sistema com 100 entidades e 150 BOs. Você vai ter uma infinidade de classes dentro de um mesmo pacote. O que eu costumo usar é separar por módulos, que conversam entre si através de interfaces. Por exemplo: módulo de autenticação tem pacotes com suas entidades e BOs, módulo de gerenciamento de pedidos, módulo de gerenciamento de produtos, etc, etc. Quanto mais você dividir e componentizar sua aplicação, melhor. Então nesse caso, a dica que eu dou é: evite os pacotes genéricos demais. A nao ser que a aplicação seja extremamente pequena e focada.

A divisão de camadas que costumo usar é, por exemplo:

Módulo Corporativo (EJB):
Interface para fachada do módulo da aplicação > [implementado por] >> Session Bean que disponibiliza os prncipais métodos para o módulo > [utiliza] >> Classes de Negócio (Sessionbeans EJB) >>> utiliza >>> Interface de gerenciamento de persistência >> [implementado por] >> Session Bean que utiliza o EntityManager >>>[manipula] >>> Entidades (JavaBeans)

Módulo Web - interface gráfica:
Páginas XHTML >>> [acessam] >>> JSF Managed Beans >>> [acessam] >>> Interface para fachada do módulo da aplicação

Então, como se pode ver, MVC não é separar a aplicação em tres pacotes (model, controller e view) e jogar tudo de qualquer jeito lá dentro. Mas sim, a forma como você organiza a responsabilidade dos seus componentes, independentemente dos pacotes em que eles estejam.

[/quote]

Diego, a questão é que eu sempre divido meu sistema em módulos e dentro desses módulos que ficam esses pacotes.

Ex: Modulo financeiro
br.com.meusistema.financeiro.bean
br.com.meusistema.financeiro.dao
br.com.meusistema.financeiro.bo
br.com.meusistema.financeiro.gui

Modulo RH
br.com.meusistema.rh.bean
br.com.meusistema.rh.dao
br.com.meusistema.rh.bo
br.com.meusistema.rh.gui

Os pacotes que ficam externos a qualquer módulo, é porque são utilizados por todos os módulos, Exemplo: Classe PessoaFisica. Fica em br.com.meusistema.bean, fora de qualquer módulo pois ela é utilizada por todos.

#70

Então estevan3180. A discussão era justamente essa, que deixar de usar os nossos JavaBeans simples para representar entidades não seria a prática mais adequada, visto que a alternativa pra isso seria iria misturar a lógica de domínio e os recursos de persistência. Sendo assim, a minha opinião é que devemos separar as responsabilidades: na nossa camada de modelo teremos as entidades, acessadas pelo EntityManager, e na camada de controle teremos as classes que contém a lógica que negócio, que irão manipular as entidades persistentes através de injeção de dependência ao entityManager.

#71

DiegoPessoa, o que deve ser levado em consideração é onde e como se trabalha também. Se a pessoa trabalha em um empresa que fabrica software de todo tipo, infelizmente não há outra alternativa, e deve-se trabalhar dessa forma mesmo - pois é mais produtivo, apesar de ir contra alguns princípios da OO. Já quem produz software “caseiro”, apenas pra empresa em que trabalha, tem mais liberdade e tempo disponíveis, podendo planejar melhor a arquitetura.

Tá muito bom esse debate aqui, a tarde volto. Abraços.

#72

Eu sou totalmente contra isso também. Na realidade, utilizo DAO, que em minha opinião, resolve todos os problemas sem criar nenhum outro - já que tomo muito cuidado para não deixar lógica alguma dentro delas.
Pense da seguinte maneira: DAO é uma necessidade, um requisito funcional do sistema - ele já está modelado, só preciso persistir. Escrevendo DAOs dessa maneira, você evita de ficar jogando lógica dentro delas.

#73

Acho que repository trataria melhor esse problema, não concorda? Desde que seja indicado desde o início que a persistência possa ser trocada um dia.

#74

Concordo que é necessário ter uma alternativa, mas você não acha que está trocando um erro por outro? Afinal, você está deixando sua classe coesa, porém, pode deixar um buraco na lógica dela, ou o pior, criar classes fantoche. Eu não concordo com nenhuma dessas duas práticas - Active Record e JavaBeans.

Leu o artigo que postei? Qualquer coisa está aqui: http://www.arquiteturajava.com.br/livro/cuidado-com-o-modelo-anemico.pdf
Aí explica o porque de se evitar essa prática.

Claro que podem haver casos em que ter um setter não vai afetar sua lógica, mas você poderá se acostumar com essa prática e fazê-la sem pensar nos problemas que podem trazer.

Abraços a todos vocês.

#75

DiegoPessoa, leia isso, por favor: http://www.martinfowler.com/bliki/AnemicDomainModel.html

#76

Eu sou totalmente contra isso também. Na realidade, utilizo DAO, que em minha opinião, resolve todos os problemas sem criar nenhum outro - já que tomo muito cuidado para não deixar lógica alguma dentro delas.
Pense da seguinte maneira: DAO é uma necessidade, um requisito funcional do sistema - ele já está modelado, só preciso persistir. Escrevendo DAOs dessa maneira, você evita de ficar jogando lógica dentro delas.[/quote]

$ERVER,
Fiquei curioso pra saber como você transporta os dados da lógica de domínio para o DAO sem usar JavaBeans

#77

Eu gostei muito das considerações do Diogo. Um ponto fundamental é entender que o MVC divide em 3, e somente 3, camadas, a model, a view e a controller. Porém, ele NÃO ESPECIFICA onde a persistência aparece. Já houve, inclusive, um tópico bastante longo aqui onde discutimos se a persistência era ou não parte do model, e a conclusão final é que:
a) Se você considerar que não é, ela é de uma camada ABAIXO do model, que não está descrita no MVC;
b) Se você fizer questão de enquadrar em uma das caixas do MVC, estaria sim dentro do model. Porém, o model seria subdivido em outras caixas.

Então, é importante entender até onde vai o escopo do que o MVC prega. Ele:
a) Não leva em consideração TECNOLOGIAS ESPECÍFICAS. Ele não está nem aí se você usa POJOS, VOs, BOs, DTOs ou qualquer outro “Os” que você queira. As técnicas foram criadas para tentar reforçar um ou outro aspecto do modelo, é importante entender o contexto histórico e que aspecto é esse;

b) Não leva em consideração a persistência. Em princípio, considera-se sempre que o modelo existe e está disponível. Então, DAOs e DTOs estão fora do escopo da discussão. Eles vão sim aparecer em algum momento, mas eles estão DO MODELO PARA BAIXO. Lógico, o erro é quando vc cria bindings, que põe eles acima do modelo, e aí sim, vale a pena discutir se o ganho do RAD será mais produtivo do que a perda causada pela quebra da separação em camadas (e as vezes, pode até ser);

c) Leva em consideração que a camada de view e modelo precisam estar FORTEMENTE SEPARADAS. E quem garante essa separação é o controller. Não é à toa que em sistemas desktop, onde o modelo está “grudado” na View, o controller acaba degenerado e tem parte das atribuições misturadas ao model (uma arquitetura reforçada pelo Swing chamada de simplified MVC).

O mesmo tipo de observação deve ser feito em torno de cada uma das outras tecnologias. É como montar um carro. Não adianta tentar inserir uma turbina num veículo qualquer, sem entender para que a turbina foi criada, para que serve e o objetivo que se tem com o carro.

Por isso sempre acabamos confusos na hora de montar um sistema. É importante entender o papel de cada parte, caso contrário, você vai ler muita coisa contraditória. Sem falar que montar uma peças erradas acabam gerando sistemas complexos e difíceis de manter.

#78

[quote]$ERVER,
Fiquei curioso pra saber como você transporta os dados da lógica de domínio para o DAO sem usar JavaBeans[/quote]

Partindo do ponto que não uso framework ORM, eu passo tranquilamente como parametros dos métodos.
Talvez você esteja confundindo o que é JavaBean. Nada mais é do que uma classe que possui apenas os atributos e getters / setters para eles, deixando a lógica isolada em outra classe.
Eu uso POJOs, em vez de JavaBeans - apesar de ter me confundido no começo do tópico legando que os dois eram a mesma coisa.

#79

Se você cria suas classes espelhando as tabelas do banco de dados, corre o risco de ter uma classe AutorLivro, ou algo parecido que já vi em inúmeros tutoriais. Muitos alegam que não há outra maneira, mas eu lhe pergunto: então devemos sacrificar a Orientação a Objetos, visto que os frameworks lhe forçam a fazer isso? Eu discordo desta maneira de programar.

#80

Olá ViniGodoy, que bom você por aqui, sempre fui um grande admirador seu!

Então, quanto à persistência, meu ponto de vista é o seguinte: não está na camada de modelo, visto que a persistência é um requisito funcional da aplicação. Porque ela é um requisito funcional? Para chegar a isso, devemos nos perguntar o seguinte: quem necessita da persistência? Resposta: o sistema.
Agora, vamos nos indagar sobre o MVC. Para que utilizar uma arquitetura MVC? Resposta: para separar as responsabilidades. Isso não seria um requisito funcional também? Resposta: não, pois tanto podemos utilizar quanto não utilizar essa arquitetura.
Considerar que a persistência deve estar no modelo, é como colocar a TV em cima da geladeira por falta de espaço na rack: ninguém lhe impede de fazer isso, mas não é o local correto dela.

E o porque disso? Resumindo: MVC trata de separar responsabilidades, não trata das tecnologias envolvidas, como você brilhantemente acabou de nos apontar. Ou seja: um sistema em MVC pode ou não ser persistido. Então, quando o MVC foi idealizado, creio eu que pensaram nisso: se não há garantia que o sistema será persistido, pra que colocaremos algo relacionado a persistência na arquitetura? E não estando na descrição da última, o que se torna? Resposta: requisito funcional - ou infraestrutura, como ACHO que alguns chamam.