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?
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…
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
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)
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 ???
[quote=baudamix]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[/quote]
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.
[quote=Giulliano][quote=baudamix]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[/quote]
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.
[/quote]
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.
Eu pensei em BO e Model (VO,DTO) porque é um sistema pequeno, basicamente com cruds apenas a parte pesada será feita via web services.
Mas, queria usar spring e hibernate para aprender a usar e da melhor maneira,por isso o post.
Entendi que não devemos usar BO, mas como fariamos chamadas a nossa camada de persistência?
Diretamente do Faces?
Usando EJB, teriamos o façade, mas sem EJB o que utilizariamos?
Bem sempre vão existe Domínio do modelo do negócio o que eu quis dizer é só para evitar separa regras de negocio que um objeto pode ter com ele exemplo criar um BO para autenticar um usuario ou para manipular objeto onde esse objeto poderia fazer isso por ele msm… isso seria msm coisa de ter um VO/BO…
Mas se a ideia do seu BO for um cara diferente do artigo tudo bem, mas o nome BO está mto ligado a VO/BO/DTO…
