Eu estou montando uma arquitetura pela primeira vez, devido a isso gostaria de usar as melhores técnicas possíveis.
Todas as vezes que eu vi alguém usando BO era para delegar regras de negócio a essas classes, por exemplo, digamos que você tenha uma funcionalidade de fazer uma tarefa x.
E antes de persistir a tarefa x, você precisa fazer n calculos.Você faria esses calculos no BO, e dpeois passar para a persistência, bgem como o inverso ,se o retorno do DAO, precisasse de alguns 'ajustes" você o faria no BO. Isso que entendi como utilidade do BO.
Respondendo a pergunta: Sim, isso seria um bom design a princípio, mas o que é certo ou errado depende do contexto.
A hierarquia de pacotes lhe dá uma idéia genérica a respeito do que você irá usar.E postei um exemplo com códigos de como funcionaria a arquitetura a principio…
[quote=pcalcado]
Não sei porque a pessoa sugeriu isso mas… qual o problema em ter uma Façade que através de AOP ou anotações faz commit na sessão após ser executada?[/quote]
Acho que sugestão e opnião depende de experiência e gosto, não?Eu estou apenas colhendo informações sobre o que seria interessantre ou não usar, para fazer da melhor maneira possível.Por isso postei códigos, divisão de pacotes,etc. Não sei como faria isso de ter uma façade para AOP ou via anotações pois como disse anteriormente estou usando spring pela primeira vez, então estou tentando usar da maneira mais simples.
Outra dúvida, o controle de transações residira aonde nessa arquitetura?
As classes de negócio (services) seriam façades para invocar os DAOS?
Pelo que li (aqui) o façade seria apenas uma abstração para você chamar sua camada de persistência.
Mas no meu caso onde o sistema não dispõe de tanta complexidade, seria realmente necessário usar um façade?
Eu pensei em faces(view)->services->dao
Simples e objetivo ou existe algum anti-pattern nisso?Onde a camada de service, faria o controle de transações (ainda não sei como, via spring provavelmente)
Esse é o exemplo clássico de BO. É uma quebra da filosofia de Orientação a Objetos e só deve ser usado se você sabe exatamente o que está azendo e porque Não pode resolver seu problema com orientação a Objetos. Não assuma esta estratégia por default, ela deve ser uma op’ão usada quando necessário -e isso é bem raro.
Um esquema de pacotes Não me diz anda sobre a arquiterura que voce está usando, apenas como você divide seus namespaces.
Leia a documentação do Hibernate, Spring e EJB 3. Lá existem soluções para isso bem mais simples.
[quote=antoniopopete]
Simples e objetivo ou existe algum anti-pattern nisso?Onde a camada de service, faria o controle de transações (ainda não sei como, via spring provavelmente)[/quote]
Não dá para ser ‘simples e objetivo’ neste contexto, para aprender arquitetura de sistemas você precisa estudar sobre arquitetura de sistemas. Dê uma olhada na bibliografia referenciada neste tópico.
Realmente não devemos seguir a risco o que diz a Sun.
Talvez eu não esteja preparado para discutir esses assuntos pcalçado, por que na minha visão um Domain Model é uma classe Modelo que esta contida no Domino referente a ela. Assim como um BO esta contido num Dominio com o intuito de fazer o mesmo serviço.
Enteni que o Domain Model é um conceito que vem para subistituir o BO. Não que eu deva DEIXAR de usar BO mas agora temos uma alternativa a ele quando não achar uma solução elegante usar BO.
Quanto ao fato de ler sobre Novos Patterns eu já tentei fazer isso, mas não é possível aprender um Pattern se eu não tiver um problema para aplica-lo. Então quando aparecer um problema que o DAO não resolva eu vou ler sobre alguns outros. Ler por ler não me faz entender onde aplicar.
[quote=Giulliano]
Quanto ao fato de ler sobre Novos Patterns eu já tentei fazer isso, mas não é possível aprender um Pattern se eu não tiver um problema para aplica-lo. Então quando aparecer um problema que o DAO não resolva eu vou ler sobre alguns outros. Ler por ler não me faz entender onde aplicar.[/quote]
Padrões são membros de uma linguagem. A sua frase equivale mais ou menos a “Não é possivel aprender palavras novas se eu não tiver uma frase onde as usar”. Isso é obviamente falso.
Vc sim pode aprender. O que vc pode não fazer é apreciar o poder do padrão. Isso, realmente só com experiencia. Mas se vc não conhece o padrão em primeiro lugar como vai usá-lo ou sentir a necessidade de usá-lo ?
Não. A minha frase não é equivalente a essa sua frase. Aliás eu comecei a ler sobre Patterns de uns tempos pra cá. Mas não entendia muito bem, até achei que fosse imaturidade minha. Aí durante o curso FJ-91 da Caelum o Nicco (professor) apresentou alguns Patterns e exemplos reais de uso do Patterns. Putz aí sim aprendi e sei até usar só de ver um exemplo bacana. Agora vai lá no wikipedia e busca por GOF. Leia sobre os patterns vc pode até saber como funciona mas falta o contexto real de onde aplicar aquele design. Arquitetura é um assunto muito delicado são cabeças diferentes pensando de maneiras diferentes para problemas iguais.
Não é tão simples assim estudar Designs Pattenrs. São mais de 30 diferentes e ainda existem combinações entre diversos gerando outros patterns. Então na minha opnião quando eu tenho um problema penso em Orientação a Objeto e tento resolver, às vezes acabo usando um Pattern sem saber que estou usando, simplesmente pq aquela foi uma solução plausível.