Opnião de arquitetura

Pessoal,

estou fazendo um projeto da faculdade e pretendo utilizar jsf 1.2+richfaces 3.2+spring 2.5+hibernate 3.2.
A atual hierarquia de pacotes que meu projeto se encontra é:

faces
bo
dao
util
exceptions

Para criar os DAO, vou usar os Spring templates e queria usar um factory do spring para fornecer DAO para o BO, para o mesmo cuidar das regrasa de negócio.

Bem, a pergunta é.
O que vocês acham da arquitetura?Ouvi falar de spring-annotations, mas ele caberia usar nesse projeto?
Tenho algumas dúvidas como:

DAO e BO, ainda são padrões utilizados hoje em dia. A idéia de usar o spring dessa maneira, está correta?

Eu acho que não tem nada demais.

Quanto ao BO e DAO, sempre irão existir enquanto houver regras de negócio e persistência de informação no sistema.

Thread.start() Membro desde: 29/02/2008 13:02:49 Mensagens: 48 Offline

Sei lá... já que vai usar hibernate e tal... que tal implementar o conceito de repositório? O que o pessoal acha, não é um conceito mais "novo" do que o DAO? Digo isso porque também gostaria de saber como ficaria uma hierarquia de projeto baseado em repositório...

Desenterrando antigos.

Dê uma olhada nesse aqui do Shoes: http://fragmental.com.br/wiki/index.php/Evitando_VOs_e_BOs

Até.

nbluis wrote:Desenterrando antigos.
Dê uma olhada nesse aqui do Shoes: http://fragmental.com.br/wiki/index.php/Evitando_VOs_e_BOs
Até.

Mas ele não tem classes VO...

esquece BO VO DTOs... isso é uma herança porca da Core da Sun... da uma olhada nas discussões aki no GUJ sobre DDD Domal-Drive Design e da uma olhada no link de cima.

acho que vc vai gostar das ideais expostas nas post

Thread.start() Membro desde: 29/02/2008 13:02:49 Mensagens: 48 Offline

Mas se for usar nTiers (camadas remotas) teria que ter VOs (ou TOs, como preferir), tudo depende da arquitetura.

Giulliano wrote:

nbluis wrote:Desenterrando antigos.
Dê uma olhada nesse aqui do Shoes: http://fragmental.com.br/wiki/index.php/Evitando_VOs_e_BOs
Até.

Mas ele não tem classes VO...

O que seria um BO sem um VO ?

zwingli wrote:Mas se for usar nTiers (camadas remotas) teria que ter VOs (ou TOs, como preferir), tudo depende da arquitetura.

Dai Sim.
Só muda o nome do Boi. DTO

This message was edited 1 time. Last update was at 24/04/2008 13:37:52

então vc pode considerar a idéia de Objetos ricos e evitar de delegar tarefas que são de responsabilidade do seu objeto para outro nada a ver com o domínio do seu objeto.
E em vez de chamar seu objeto de domínio de BO pode chamar de POJO o (velho e simple Objeto java)

Thread.start() Membro desde: 29/02/2008 13:02:49 Mensagens: 48 Offline

E como fica a hierarquia do projeto?? Mantém BO, usa uma pasta POJO ou como ficaria ? Alguém tem um projeto "rico" sem VO, DTO, Eticeterou para dar uma sugestão ???

baudamix wrote:esquece BO VO DTOs... isso é uma herança porca da Core da Sun... da uma olhada nas discussões aki no GUJ sobre DDD Domal-Drive Design e da uma olhada no link de cima.
acho que vc vai gostar das ideais expostas nas post

Volto a repetir...um BO sempre vai existir. Desde o inicio do univeros um sistema não existe se não existe uma necessidade (traduza necessidade para regra de negócio)

O artigo é sem dúvida muito bom, só não estou vendo o que isso trem haver com a arquitetura acima. A idéia de criar classes de Dominio sempre refletindo o modelo do negócio de cliente é uma boa prática...porém BO e Dominio dá na mesma.

Giulliano wrote:

baudamix wrote:esquece BO VO DTOs... isso é uma herança porca da Core da Sun... da uma olhada nas discussões aki no GUJ sobre DDD Domal-Drive Design e da uma olhada no link de cima.
acho que vc vai gostar das ideais expostas nas post

Volto a repetir...um BO sempre vai existir. Desde o inicio do univeros um sistema não existe se não existe uma necessidade (traduza necessidade para regra de negócio)

O artigo é sem dúvida muito bom, só não estou vendo o que isso trem haver com a arquitetura acima. A idéia de criar classes de Dominio sempre refletindo o modelo do negócio de cliente é uma boa prática...porém BO e Dominio dá na mesma.

Entendo seu ponto de vista.

A unica confusão aqui é que todo mundo entende BOs como aqueles Business Objects que vem acompanhados dos VOs como estruturas de dados e seus getters and setters.
E é isso que a galera está tentando erradicar.

Até.

nbluis wrote:
O que seria um BO sem um VO ?

Um BO como o artigo diz seria uma classe com o método autenticar e o VO seria uma classe com atributos Login e Senha. O BO recebe um VO.

Um Domínio ou um BO (pensando em Good Citizen) já possui tudo o que for preciso para fazer o login...

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

zwingli wrote:Sei lá... já que vai usar hibernate e tal... que tal implementar o conceito de repositório? O que o pessoal acha, não é um conceito mais "novo" do que o DAO? Digo isso porque também gostaria de saber como ficaria uma hierarquia de projeto baseado em repositório...

Repositorio não é um conceito que substitui DAO!
São objetos com responsabilidades diferentes.

O DAO serve para encapsular a comunicação com o JDBC e/ou outras API de persistencia.

O Reposiorio serve para centralizar as pesquisas de um forma OO. Ele usa o DAO para executar essas pesquisas.

Notícias, artigos e o maior fórum brasileiro sobre Java