Business Object VS 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 ?

Veja essa imagem:

http://pt.wikinourau.org/pub/GrupoWeb/SlidesPadraoMVC/mvc-structure-generic.gif

o que é

lógica da aplicação

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.

$ERVER:

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?

então se utilizarmos active records (crud no proprio objeto / Java Bean) a lógica de negócio ficará neste também, correto ?

$ERVER:

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.

Exato, camarada!

Isso é uma prática que divide opiniões, também.
Em minha opinião, fazer isso deixa a classe com mais de uma responsabilidade - o que não se pode fazer na OO. Mas há quem defenda AR, e respeito muito quem o faça, é apenas minha opinião.

então drsmachado, como falei acima, na minha opinião não é algo legal pra se fazer, e pode dar problemas depois - digo isso porque já fiz e tive dores de cabeça.

Quanto aos DAOs e DTOs, ficam estranhos também, concordo contigo.

E ainda é humilde, tem todo o meu respeito!

Talvez eu esteja confundindo algumas coisas aqui, conto com a sua ajuda na correção se eu falar alguma bobeira, tudo bem?

Grande abraço aos dois!

O POJO é um elemento arraigado na mente de muitos desenvolvedores java que vieram da programação estruturada e/ou que são mais antigos. Aí eles ensinam seus alunos a usarem e isso fica arraigado nos mais novos.
Quando eu aprendi MVC, o que foi passado é o mesmo que o rlanhellas está discursando. Mas pouco a pouco você consegue ver que cada camada pode conter mais de um tipo de classe e que cada classe terá suas responsabilidades bem divididas. Aí você percebe que MVC trata de camadas e responsabilidades e não apenas de Model View Control.

Verdade drsmachado, o conceito de POJO é tão forte que fica difícil de aprender outro tão facilmente e esquecer que no Java Bean podemos fazer um CRUD também, não só Getters e Setters.

A questão que mais me incomoda é definir o que há de fato na camada MODEL do MVC, pois V são os formulários (GUI), C são os Controllers e M são os models.

Se estivermos falando de ACTIVE RECORDS então na Camada MODEL podemos considerar apenas os Java Beans com CRUDS, certo ?

Correto. Porém, deixe de usar um pouco a palavra “camada” e substitua por “responsabilidade”, metanlize isso, pois MVC é divisão de responsabilidades, e não de camadas - as camadas são divididas apenas pra organização.

rlanhellas:

Verdade drsmachado, o conceito de POJO é tão forte que fica difícil de aprender outro tão facilmente e esquecer que no Java Bean podemos fazer um CRUD também, não só Getters e Setters.

A questão que mais me incomoda é definir o que há de fato na camada MODEL do MVC, pois V são os formulários (GUI), C são os Controllers e M são os models.

Se estivermos falando de ACTIVE RECORDS então na Camada MODEL podemos considerar apenas os Java Beans com CRUDS, certo ?

rlanhellas , me responda agora: quem tem a RESPONSABILIDADE de representar algo do mundo real na aplicação?

Tem outra questão em utilizar o Active Record, como o Hibernate trata isso ?
Pelo que trabalho até hoje (com POJOS e DAOS) os CRUD’s feitos pelo Hibernate são sempre feitos em classes diferentes dos POJOS.

Os objetos ?

Exato. E você não concorda que devem ter tanto os atributos quanto as operações que a entidade do mundo real que o objeto representa?

Então, as classes de domínio - que serão seus objetos que representam quem ou o que interage com a sua aplicação - pertencem ao MODEL.

Isso não quer dizer que deva estar num package chamado “br.com.suaempresa.model”. Então, não se trata de camadas, e sim de responsabilidades.
Consegui explicar melhor ou tem algo que ficou estranho ainda?

O que pode estar lhe confundindo são os requisitos funcionais - uma determinada condição pra aplicação continuar sua execução normal. MVC não trata disso - isso é tratado com Orientação a Aspectos, outra técnica de programação que usa reflexão computacional, e tem seu uso muito controverso na comunidade também.

Ficou claro sim, a responsabilidade da lógica de negócio deve estar toda no próprio objeto.

PORÉM, TODAVIA, ENTRETANTO, isso não iria deixar o mesmo sobrecarregado ? Uma SUPERCLASSE de 5mil linhas ? Pois além de ter os seus getters e setters ainda terá: CRUD, sessões hibernate, injeção de dependência e outros recursos necessários.

Agora eu gostei, acho que entendeu.

É por isso que sou contra o CRUD no objeto, e qualquer responsabilidade atribuída a classe que não seja relacionada ao domínio.

Cada um dos recursos que você citou, não são nativos do Java - apesar da maioria ter suas especificações para guiar o desenvolvimento de ferramentas que as façam - portanto, se precisa delas, recorra as essas ferramentas.

Resumindo: por MODEL entenda que são suas classes - as quais tem apenas seus atributos e métodos com as operações que elas realizam.

Eu imagino que já devo estar te deixando nervoso, porque to só no bla bla bla até agora, mas MVC no começo é assim mesmo, teoria de começo.

Nervoso nada, alegre por conseguir essa quantidade de conhecimento em tão pouco tempo rsrsrs.

A questão amigo sobre usar ACTIVE RECORD, para não sobrecarregar a Classe, poderíamos usar o padrão DAO + Repository. O que acha ?

Desculpe mas a definição de POJO não é simplesmente de um objeto anêmico com getters e setters…
Embora POJO na minha opnião, não seja nada mais que um objeto Java comum (diferente de um EJB que implementa determinadas interfaces), nada impede dele ter lógicas de negócio e não ser um objeto anêmico.

Martin Fowler tem uma boa definição sobre POJO:

Minha ideia é o seguinte, para minha aplicação MVC:

1 - br.com.meuprojeto.bean (Todos os POJOS ficam aqui)
2 - br.com.meuprojeto.dao (Todos os DAOS ficam aqui)
3 - br.com.meuprojeto.bo (Todos os Business Object ficam aqui e se comunicam com o DAO, como se fosse um Repository)
4 - br.com.meuprojeto.bd (Business Delegate - é o Controller)
5 - br.com.meuprojeto.gui (Frames da aplicação)

rlanhellas:

Minha ideia é o seguinte, para minha aplicação MVC:

1 - br.com.meuprojeto.bean (Todos os POJOS ficam aqui)
2 - br.com.meuprojeto.dao (Todos os DAOS ficam aqui)
3 - br.com.meuprojeto.bo (Todos os Business Object ficam aqui e se comunicam com o DAO, como se fosse um Repository)

4 - br.com.meuprojeto.gui (Frames da aplicação)

Desculpe mas dessa forma sua aplicação tende a ficar procedural.

Faça com que seus Pojos não sejam simples beans e sim implemente lógicas de negócio e que eles sejam o ponto de partida para façades de serviço (até pode chamar de BO) que façam a parte de repositório.

Sempre cito o seguinte exemplo:
A classe Conta possui os métodos deposito() e saque(), mas jamais o método transferência (que muita gente cita que faz parte da classe conta).
Transferência é um serviço que ocorre em 2 contas (origem e destino), onde é realizado o saque da origem e deposito da destino, em um contexto transacional e que pode ser chamada por diversos outros dominios do sistema, por exemplo, um funcionario fazer uma transferência ou ainda um cliente a realizar.

Ele pode ter mais do que getters / setters sim.
Porém, precisa de getters / setters para todos seus atributos. E isso pode atrapalhar a modelagem, e até a codificação.

Ele pode ter mais do que getters / setters sim.
Porém, precisa de getters / setters para todos seus atributos. E isso pode atrapalhar a modelagem, e até a codificação.

Não entendo assim… posso estar errado, mas qual seria o motivo disso ??? Um objeto java simples conforme definido por Fowler pode implementar suas regras de negócio usando simplesmente OO e mais nada… o que o caracteriza como um objeto puro é não implementar nenhum interface como por exemplo um EJB.
Não entendo onde isso atrapalhe a modelagem ou codificação…
O padrão javabean sim dita ter getters e setters para tudo.

E na minha visão POJO != JavaBean

Sempre cito o seguinte exemplo:
A classe Conta possui os métodos deposito() e saque(), mas jamais o método transferência (que muita gente cita que faz parte da classe conta).
Transferência é um serviço que ocorre em 2 contas (origem e destino), onde é realizado o saque da origem e deposito da destino, em um contexto transacional e que pode ser chamada por diversos outros dominios do sistema, por exemplo, um funcionario fazer uma transferência ou ainda um cliente a realizar.

E eu acho que POJO == JavaBean.

Posso estar errado e falando bobeira, mas só mudo de opinião depois de ler algum artigo que prove o contrário.

alias, se eu estiver errado e você tiver algum artigo que prove, fico muito grato se me passar - evitaria eu falar algo errado novamente.

$ERVER:

E eu acho que POJO == JavaBean.

Posso estar errado e falando bobeira, mas só mudo de opinião depois de ler algum artigo que prove o contrário.

Você leu a definição de POJO do Martin Fownler ???

An acronym for: Plain Old Java Object.

The term was coined while Rebecca Parsons, Josh MacKenzie and I were preparing for a talk at a conference in September 2000. In the talk we were pointing out the many benefits of encoding business logic into regular java objects rather than using Entity Beans. We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it’s caught on very nicely.

jmmenezes:

rlanhellas:

Minha ideia é o seguinte, para minha aplicação MVC:

1 - br.com.meuprojeto.bean (Todos os POJOS ficam aqui)
2 - br.com.meuprojeto.dao (Todos os DAOS ficam aqui)
3 - br.com.meuprojeto.bo (Todos os Business Object ficam aqui e se comunicam com o DAO, como se fosse um Repository)

4 - br.com.meuprojeto.gui (Frames da aplicação)

Desculpe mas dessa forma sua aplicação tende a ficar procedural.

Faça com que seus Pojos não sejam simples beans e sim implemente lógicas de negócio e que eles sejam o ponto de partida para façades de serviço (até pode chamar de BO) que façam a parte de repositório.

Sempre cito o seguinte exemplo:
A classe Conta possui os métodos deposito() e saque(), mas jamais o método transferência (que muita gente cita que faz parte da classe conta).
Transferência é um serviço que ocorre em 2 contas (origem e destino), onde é realizado o saque da origem e deposito da destino, em um contexto transacional e que pode ser chamada por diversos outros dominios do sistema, por exemplo, um funcionario fazer uma transferência ou ainda um cliente a realizar.

Se eu utilizar da forma que você cita, colocar todo CRUD direto no meu POJO, então não estaria sobrecarregando o mesmo e quebrando o conceito de DDD ? (Domain-Drive Design) ?

Quando Martin Fownler definiu POJO não fez nenhuma relação direta com javabean… agora, se depois ele fez isso de alguma outra forma então também estou errando chamando de POJO o que não é…

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!

rlanhellas:

jmmenezes:

rlanhellas:

Minha ideia é o seguinte, para minha aplicação MVC:

1 - br.com.meuprojeto.bean (Todos os POJOS ficam aqui)
2 - br.com.meuprojeto.dao (Todos os DAOS ficam aqui)
3 - br.com.meuprojeto.bo (Todos os Business Object ficam aqui e se comunicam com o DAO, como se fosse um Repository)

4 - br.com.meuprojeto.gui (Frames da aplicação)

Desculpe mas dessa forma sua aplicação tende a ficar procedural.

Faça com que seus Pojos não sejam simples beans e sim implemente lógicas de negócio e que eles sejam o ponto de partida para façades de serviço (até pode chamar de BO) que façam a parte de repositório.

Sempre cito o seguinte exemplo:
A classe Conta possui os métodos deposito() e saque(), mas jamais o método transferência (que muita gente cita que faz parte da classe conta).
Transferência é um serviço que ocorre em 2 contas (origem e destino), onde é realizado o saque da origem e deposito da destino, em um contexto transacional e que pode ser chamada por diversos outros dominios do sistema, por exemplo, um funcionario fazer uma transferência ou ainda um cliente a realizar.

Se eu utilizar da forma que você cita, colocar todo CRUD direto no meu POJO, então não estaria sobrecarregando o mesmo e quebrando o conceito de DDD ? (Domain-Drive Design) ?

Não… você não vai colocar todo seu CRUD no seu pojo… e sim as regras de dominio em cada um deles…
Veja o exemplo que citei da Conta e da transferência.
O Fluxo deve ser gerenciado por um controller ou presenter… ele que será responsável pelo fluxo destas!

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!

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

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!

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

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

Aqui tem boas definições e uma explicação sobre as diferenças entre javaBean, POJO e Spring Bean.
Aqui uma descrição da wikipedia (em idioma bretão) sobre ambos. Notem que há uma certa confusão também.
Particularmente, entendo que POJO pode ser sempre um JavaBean, mas um JavaBean só é um POJO às vezes.

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!

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

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

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.

Pois é, realmente eu estava enganado, confundindo POJO com JavaBean.
Apesar de ter errado o nome, acho que no conceito nós pensamos igual, já que achamos que setters e getters jogados a esmo em todas as classes não são uma boa prática.
Muito obrigado por ter pesquisado e postado os resultados, agora não falo mais bobeira sobre isso.

Concordo contigo, sigo essa lógica também!

$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?

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.

Entrei no mundo Java, e consequentemente OO há poucos meses.

Sempre que procuro ler sobre DAO’s, POJO’s, DTO’s, se devem ser usados ou não, fico sempre muito confuso e não consigo formar uma opinião consistente.

O que vou falar, pode ser um absurdo, mas gostaria que dissessem o que acham:

Quais os contras de criarmos uma classe abstrata com os atributos e assinatura dos métodos de CRUD (inserir, atualizar, remover), e criarmos 2 classes (um DAO e um BO) que herdem desta classe abstrata os atributos, e implementam os métodos abstratos de acordo com sua responsabilidade, o BO tendo o método inserir para validar os dados e o DAO tendo o método inserir contendo a implementação necessária para gravar no BD?

estevan3108, é como eu falei. Esse DAO genérico, que você se refere, caso você use ORM, já é disponibilizado pelo provedor de persistência, é o EntityManager. Você pode injeta-lo em qualquer classe de negócio e usar as funções de CRUD sob qualquer entidade. Já sobre criar um BO genérico, não vejo sentido. Primeiramente, Java não possui herança múltipla, então você estaria limitando os seus BOs a nunca poderem herdar de uma outra classe. Além disso, classes de negócio naturalmente são bem específicas, cada uma possui suas próprias regras e métodos diferentes. Sendo assim, não teria lógica ter uma classe genérica pra todos.

Tem razão Diego!

Ainda ficou uma dúvida, quando não usamos DTO’s ou POJO’s. Colocamos dados e lógica na mesma classe.
Como ficaria este transporte de dados por exemplo para uma classe de persistência? Partindo do princípio que lógica de domínio e persistência estão separados. Eu passaria para a classe de persistência uma instância da classe de lógica? Faz sentido?

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!

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

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

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.

…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…

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?

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.

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.

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.

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.

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.

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.

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.

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

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?

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.

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.

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.

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.

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.

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.

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.

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

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.

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

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.

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

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.

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.

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.

$ERVER:

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.

Exatamente. Era o que eu argumentava. Eu também sou da visão de que persistência não está no modelo. Mas o que quis apontar é justamente isso. Muita gente pensa: mas se não tá no modelo, não deveria estar no controle, ou na view?". E a resposta continua sendo não. A persistência não está no modelo, nem na view e nem no controle, justamente porque ela não está especificada no MVC. O MVC termina no modelo e o que você faz dali para baixo, é problema seu.

JavaBean não impede que pessoas façam escolhas equivocadas, como desenvolvedores optarem por frameworks que exigem a criação indiscriminada de setters, ou empresas contratarem programadores que não sabem o que estão fazendo.

JavaBean é apenas uma convenção pra se definir propriedades em objetos Java, algo comum em linguagens OO. Por exemplo, properties são uma mão na roda em Objective-c, e C# introduziu o conceito de automatic properties a partir da versão 3.0.

+1. Espelhar o banco de dados é o contrário de fazer design OO e costuma resultar em uma arquitetura procedural.

Persistência relacional é um câncer, em termos de OO.

Já viram o quão elegante fica os objetos de um game ou simulador complexo, que quase não persiste nada? Chegam a ser poeticamente bonitos.

Persistência relacional é um câncer, em termos de OO.

Já viram o quão elegante fica os objetos de um game ou simulador complexo, que quase não persiste nada? Chegam a ser poeticamente bonitos.

Infelizmente nunca vi, vou até dar uma pesquisada, me deixou com água na boca!
Outra coisa que anda me deixando curioso são bancos de dados orientados a objeto. Há alguns anos fiz uma pesquisa no google pra ter uma idéia, mas muitos diziam que eles não são performáticos, mas nunca testei.

Ano passado estudei um pouco de Hibernate, e fiquei de cabelo em pé!
Eu sei que pra quem trabalha com produção de software, ele é uma mão na roda, já que deixa muito mais produtivo. Mas tem horas que aquilo vira uma gambiarra que dá medo!

O MVC termina no modelo e o que você faz dali para baixo, é problema seu.

Concordo, e essa é uma das principais dificuldades que tenho com a OO. Manter o estado do objeto sempre consistente, validando antes de setar os valores aos atributos, e o pior: tendo que persistir tudo.

Eu geralmente faço assim: os dados que vem de um formulário, valido no modelo, se for regra de negócio. Por exemplo, um usuário precisa de uma senha de no mínimo 8 caracteres, com pelo menos 2 números, e o login não pode ser deixado vazio.

public class Usuario {

  private String login;
  private String senha;

  public boolean isLoginValido(String login, String senha) {
    //aqui verifico se o login não está vazio e se a senha tem ao ao menos 8 caracteres
  }
 
}

Com isso, em meu controller:

if (usuario.isLoginValido(request.getParameter("login"), request.getParameter("senha"))) {
    //ai sim verifico no banco se o usuário está cadastrado, já que isso é requisito funcional
  }

Ando programando desta maneira, o que acham desta abordagem?

acredito $ERVER, pelo outro post que você criou, esteja respondendo de acordo com o Domain Driven Delevopment.

Tenho dúvidas que o DDD seja um padrão único consolidado em arquitetura e que todos os sistemas que não o implemente sejam gambiarras (posso ser convencido com mais informações).

isso é pano para muita discursão:
http://blog.fragmental.com.br/2007/06/22/cuidado-com-domain-driven-design/

a arquitetura Web que aprendi na Faculdade foi o basicao sem frameworks:

GUI(View) => Controller(Servlet´s) => Facade(Design Patterns) => Classes Controladoras(uma para cada entidade contendo Regras de Negócio usando o Modelo e fazendo a comunicação com DAO) => DAO.

Fica algumas Dúvidas:

esta Arquitetura(acima) não é utilizada comercialmente?

É somente uma arquitetura conceitual?(só serve para fins de aprendizado).

Ao estagiar em uma empresa encontrei um Analista que tinha trabalhado em algumas fábricas de software e era um bom programador Java, quando formos desenvolver uma aplicação fiquei ansioso para saber qual a arquitetura iria se utilizada pois ele por ter alguma experiência deve ter conhecido várias e ao discutir o sistema ele falou que a arquitetura seria a mencionada acima(a exceção de ter utilizado o Wicket na View/Controller), fiquei surpreso pois mesmo sendo a que conhecia achava que poderia está obsoleta ou que escolheria outra mais eficaz.

No final a aplicação foi desenvolvida e saiu como esperado.

Aprendi que as Entidades mantém o estado e o comportamento do objeto nada mais e que não deve ter métodos com regras de negócio.

Lógico que a tecnologia evolui tudo pode mudar.

Acredito que aplicação deve ser desenvolvida orientada ao cliente e satisfazer suas necessidades entregando algo de valor ao mesmo conforme desejou e pagou.

Então, Alexsandro Lopes, tudo o que sei sobre DDD até agora é muito pouco, baseado em 2 artigos que li e muita coisa postada por outros usuários aqui. Comprei ontem o livro Domain-Driven Design - Atacando as Complexidades no Coração do Software, de Eric Evans, agora é esperar chegar e ler, pra tirar as conclusões.

Chegou em um ponto muito interessante, mas não se esqueça de que teríamos que entender o porque a arquitetura não é utilizada comercialmente. Lembro-me das aulas que tive em uma empresa - localizada aqui em minha cidade - oferecido em um curso visando contratar estagiários. O curso era de OO e C#. A maneira como passaram a programar em C#, era idêntica aos “modelos anêmicos” descrita pelo Fowler. E se trata de uma grande empresa, que tem contratos com outras grandes empresas do Brasil. Um certo dia no curso, perguntei ao nosso instrutor exatamente sobre isso, porque nos era passada aquela forma de programar, se não era a correta conceitualmente - nós já tínhamos tido aulas de OO na faculdade. Ele nos respondeu simplesmente que é como a maioria sabe programar. e que mudar isso poderia levar muito tempo. Como todos sabemos, se uma empresa desse porte resolve mexer nisso, vai levar muito tempo para que a adaptação seja feita em 100% - mesmo que isso seja feita gradualmente.
Eu não acredito que a forma que todos dizem ser a “comercialmente viável de programar” seja a única. Tanto que desisti de trabalhar em empresas desse porte por conta disso: todos sabem que estão fazendo errado, e continuam a fazer como isso não fosse nada. “Se está funcionando assim, pra que mexer?”

Aí estão outros dois pontos que são muito discutidos hoje em dia.

1 - O papel do analista, o que ele faz, o que teve que estudar na graduação, etc. Mas nem vou entrar nesse mérito porque não acho necessário.
2 - Fábricas de software. Esse é outro ponto crucial. O que prega a OO? O desenvolvimento das aplicações fortemente baseadas no negócio. Então, imagine uma empresa que crie sw para todo tipo de negócio. Não acha isso uma contradição? Deve estar pensando, “ai entra o analista”. Sim, porém, o tempo para essa etapa também é curto, e o negócio que deve ser tratado pelo sw pode não ser bem entendido. Por essas e outras questões, acho que a fábrica de software é hoje em dia obsoleta - eu e mais um punhado de autores de engenharia de sw.

Talvez eu não tenha entendido, mas achei uma contradição ai. Como vou manter 100% o estado do objeto se não aplico as regras de negócio nele? Se eu deixar que alguém o altere externamente, de acordo com alguma condição, não seria uma regra? E essa regra não seria do domínio?

Concordo em partes contigo, pois me parece que geralmente o cliente e pede um programa em linguagem “x”. Pra ele não interessa nada se é OO - a maioria nem sabe o que é isso mesmo. Mas perceba que o que discutimos aqui é diferente. Um sistema pode ser escrito em qualquer linguagem, com quaisquer padrões - e até anti-padrões, como a modelagem anêmica - e terá a mesma aparência pro usuário final. Porém, a diferença entre eles quanto a qualidade e facilidade de manutenção será gritante. A OO foi criada com esse propósito, a qual a diferencia em relação a programação estruturada. Agora, se vamos utilizar modelagem anêmica, a qual, segundo o próprio fowler, se parece com a programação estruturada, qual o ganho que temos com isso?
Dê uma lida neste artigo, quando puder: http://www.agileandart.com/2010/07/16/ddd-introducao-a-domain-driven-design/

Repare que eu também ainda tenho muito mais perguntas do que respostas, principalmente sobre DDD.

Muito obrigado por estar participando, e dando sua opinião. Espero que continue acompanhando o tópico, e expressando suas idéias e dando sugestões.

Abraços!

ViniGodoy:

Persistência relacional é um câncer, em termos de OO.

Já viram o quão elegante fica os objetos de um game ou simulador complexo, que quase não persiste nada? Chegam a ser poeticamente bonitos.

Isso mesmo Vini. Em jogos, a responsabilidade de garantir consistência e integridade do domain model está no processo que roda o jogo, o banco tem papel apenas de persistir o estado pra que o “mundo” possa ser restaurado do mesmo lugar que parou quando o processo foi interrompido. Diferente de sistemas corporativos que geralmente são construídos a partir da ideia que essa inteligência reside no processo que roda o banco.

Nem preciso dizer que isso não prejudica apenas nós programadores que lidamos com código, mas também a experiência do usuário que usa o sistema, tanto é que as pessoas amam jogos, na mesma proporção que odeiam sistemas de escritorio.

Nem preciso dizer que isso não prejudica apenas nós programadores que lidamos com código, mas também a experiência do usuário que usa o sistema, tanto é que as pessoas amam jogos, na mesma proporção que odeiam sistemas de escritorio.

Carlos, como gamer hardcore sou obrigado a discordar de você. Tem alguns jogos Da Eletronic Arts que hoje em dia, você vê até personagem voando pela tela - e nem super herói ele é! kkkkkkkkkkkkkk

Falando sério agora, vocês tem razão, 99% dos jogos não possuem nenhum tipo de erro, é muito raro. Mas parece que tem algumas empresas - como a EA games - que não ligam muito pra isso também.
Será que esse alto nível alcançado em games tem haver com isso mesmo? Me deixaram curioso, agora.

$ERVER:

Falando sério agora, vocês tem razão, 99% dos jogos não possuem nenhum tipo de erro, é muito raro. Mas parece que tem algumas empresas - como a EA games - que não ligam muito pra isso também.
Será que esse alto nível alcançado em games tem haver com isso mesmo? Me deixaram curioso, agora.

O alto nível é porque se a EA não criar um jogo decente, você vai gastar seu dinheiro com a concorrência. Sistemas corporativos o usuário é obrigado usar qualquer porcaria porque aquele é o trabalho dele.

Então, eu acho que me expressei mal. É que a EA faz trabalho porco, e ainda consegue vender milhões de cópias de seus jogos. Isso me parece acontecer porque, ao ler notícias sobre games e os comentários, se vê muito o que se chama de “fanboys”, aqueles que defendem uma marca com unhas e dentes. O jogo pode ser horrível, ter os piores defeitos, mas se o gamer gosta daquela empresa por qualquer motivo, defende o jogo com unhas e dentes - algo cada vez mais natural hoje em dia, não só com games, mas em vários outros segmentos, também. Essa prática parece ter sido adotada pelas próprias empresas, já que quem sai ganhando são elas - e o pessoal segue como um bando de bois indo para o matadouro.

Voltando ao foco, o que você disse faz todo o sentido: ou o cara usa aquele sistema, ou a empresa encontra outro que o use.

Abraços.

$ERVER:

Então, eu acho que me expressei mal. É que a EA faz trabalho porco, e ainda consegue vender milhões de cópias de seus jogos. Isso me parece acontecer porque, ao ler notícias sobre games e os comentários, se vê muito o que se chama de “fanboys”, aqueles que defendem uma marca com unhas e dentes. O jogo pode ser horrível, ter os piores defeitos, mas se o gamer gosta daquela empresa por qualquer motivo, defende o jogo com unhas e dentes - algo cada vez mais natural hoje em dia, não só com games, mas em vários outros segmentos, também. Essa prática parece ter sido adotada pelas próprias empresas, já que quem sai ganhando são elas - e o pessoal segue como um bando de bois indo para o matadouro.

Voltando ao foco, o que você disse faz todo o sentido: ou o cara usa aquele sistema, ou a empresa encontra outro que o use.

Abraços.

Na nossa área o maior exemplo disso é a própria orientação a objeto. Mesmo sendo comprovadamente uma maneira idiota de se lidar com dados que estão num banco de dados relacional, as pessoas continuam consumindo “produtos” sobre o assunto, como livros, cursos, etc… Até mesmo novas linguagens são veneradas pela sua capacidade de ser compatível com a “maneira OO”, e não pela sua capacidade de oferecer uma solução melhor para o problema de acessar/transformar/filtrar dados (Alô Scala!).

Típica mentalidade de rebanho em ação, igual você disse.

É o que eu sempre digo: já tá na hora de haver uma quebra de paradigma, OO tá chegando a um ponto onde se resolve uma falha e se criam outras 3. Pode-se notar isso pelo gigantesco número de frameworks que estão por aí - e o pior, eles ajudam na produtividade, mas sempre quebram alguns conceitos pra isso.

Eu gosto da OO, e como eu sempre fui meio inclinado a humanas - apesar de ter ido parar em exatas - então gosto muito de debater, perguntar, levantar dúvidas pra chegar a uma solução. OO é o melhor que temos hoje em dia, mas está longe de ser a solução perfeita, como muitos pregam por ai.

Eu também gosto de objetos quando estou criando um jogo, simulação ou mesmo algum tipo de GUI.

Mas quando quero simplesmente lidar com dados (que é do que se trata 99% dos sistemas corporativos) OO está longe de ser recomendado, muito menos é a melhor solução que temos hoje em dia. FP é muito melhor pra isso, IMO.

Eu não posso opinar sobre isso pois ainda sou muito novo na área, mas estou me dando uma chance, vou estudar como um cão sobre essas técnicas e conceitos e ver se realmente alguma delas funciona. DDD me pareceu legal e muito simples, até agora. O mais difícil anda sendo outros conceitos que aborda - repository, quando e como usar services, etc.

Quanto aos “produtos” que você citou, pode até estar certo - já que deve ser experiência própria - mas vou tentar mesmo assim. O máximo que vai acontecer é ter gasto uns R$3.000,00 em livros, A TOA! kkkkkk … Eu sei que deve tá pensando se sou louco ou playboy, mas me encaixo na primeira opção mesmo! Não tendo retorno - não quanto ao dinheiro, mas no conhecimento - mudo de área outra vez! Não gosto de coisas feitas de qualquer forma, cara, se algo não me convence, mesmo com esforço, eu caio fora.

E concordo, pra sistemas que não precisam de persistência a OO funciona que é uma maravilha! Mas ainda tenho um luz no fim do túnel, o jeito agora é estudar!

E quando eu disse

Talvez eu tenha dado opinião sobre algo que não conheço a fundo também, pois comparei apenas com a programação estruturada.

O que seria FP e IMO?

Abraços!

$ERVER:

O que seria FP e IMO?

Abraços!

FP = Functional Programming (Programação Funcional)
IMO = In My Opinion (Na minha opinião)

Acho que você está no caminho certo. Boa sorte na sua empreitada!

Muito obrigado Carlos, abraços!