Olá a todos, gostaria da sugestão de vocês para me ajudarem a decidir sobre qual arquitetura utilizar em um projeto que vamos iniciar o desenvolvimento.
Para a camada de Visual pretendo utilizar PrimeFaces e minha dúvida é o que usar na camada de persistência? As consultas devem se rápidas e a programação que tenha uma certa produtividade. O banco de dados que vamos utilizar é o PostGreSQL.
Estou na dúvida entre JPA, Spring DAO ou JDBC.
O que acham?
[quote=Licuri]Olá a todos, gostaria da sugestão de vocês para me ajudarem a decidir sobre qual arquitetura utilizar em um projeto que vamos iniciar o desenvolvimento.
Para a camada de Visual pretendo utilizar PrimeFaces e minha dúvida é o que usar na camada de persistência? As consultas devem se rápidas e a programação que tenha uma certa produtividade. O banco de dados que vamos utilizar é o PostGreSQL.
Estou na dúvida entre JPA, Spring DAO ou JDBC.
O que acham?[/quote]
As pessoas que vão desenvolver conhecem mais qual tecnologia? Tem alguma pessoa de banco de dados na equipe?
Se a performance for um requisito eu pensaria em criar as queries em procedure no banco e apenas chamar via java.
Abs
Sua pergunta é muito importante… O pessoal conhece mais JDBC e na equipe tem uma pessoa muito boa de banco de dados.
Olá, boa noite!
Se a sua equipe é assim, a ideia do André é boa… faz as procedures no BD e chama via JDBC… pronto… rápido e produtivo…
O problema que pode ter nesta abordagem é em manutenção futura, principalmente quanto a pessoa que vai construir isso no Banco de Dados (o projeto fica extremamente dependente dela e isso geralmente não é bom)… e também não é muito viável fazer uma troca desse BD futuramente… mas se não correr este risco, faça direto (como informado acima).
Abraço,
Valeu Galera…
oi,
Então, eu nunca vi um projeto grande que tivesse mudança de banco de dados, mesmo que as procedures ficassem no banco, isso só acontece quando você tem um produto cusotmizado que pode ser revendido para vários bancos de dados, minha experiência pelo menos.
Para chamar as procedures você pode usar o Spring também
Abs
Uma dúvida que tenho: alguém aí já comparou a performance de uma sp com um sql parametrizado? Em situações reais?
Imagino que a maioria dos bancos de dados hoje “compila” uma query parametrizada assim como faz com uma procedure.
Por tanto tenho dúvidas se essa diferença realmente existe e se existir, é tão gritante assim.
Se tiver alguém na equipe que conheça bem JPA, eu apostaria nele.
Ele simplifica demais boa parte do trabalho, que terá tempo para se concentrar nos gargalos, quando aparecerem.
Infelizmente não há arquitetura de caixinha que seja performática de cara.
Além de estudar boas práticas, ver exemplos de sucesso você precisa medir e monitorar sempre.
Faça testes de carga, encontre os problemas e vá corrigindo e aprimorando.
[quote=AbelBueno]Uma dúvida que tenho: alguém aí já comparou a performance de uma sp com um sql parametrizado? Em situações reais?
Imagino que a maioria dos bancos de dados hoje “compila” uma query parametrizada assim como faz com uma procedure.
Por tanto tenho dúvidas se essa diferença realmente existe e se existir, é tão gritante assim.
Se tiver alguém na equipe que conheça bem JPA, eu apostaria nele.
Ele simplifica demais boa parte do trabalho, que terá tempo para se concentrar nos gargalos, quando aparecerem.
Infelizmente não há arquitetura de caixinha que seja performática de cara.
Além de estudar boas práticas, ver exemplos de sucesso você precisa medir e monitorar sempre.
Faça testes de carga, encontre os problemas e vá corrigindo e aprimorando.[/quote]
Concordo, e alem disso, “as consultas tem que ser rapidas” é muito vago e muito pouco para valer a afirmacao “faca procedures no banco de dados e chame da aplicacao”. Isso so faz sentido em quantidades gigantes de dados ou atualizacoes em batch que poderiam demorar horas para executar. Se a aplicacao for simples isso não vale o esforço.
Sobre a afirmacao “aplicacoes grandes nao mudam de banco” eu posso dizer que ou eu sou azarado ou esta afirmacao nao é tao precisa assim. Eu trabalho com desenvolvimento ha 12 anos e estou participando da minha quarta migração de banco. Uma delas de um sistema muito grande, que já foi concluida, outra de um gigante, que esta congelada porque o sistema esta extremamente amarrado com a base (so em procedures sao mais de 2000, fora triggers e sql especifico), enquanto isso a empresa vai pagando um absurdo de licença do banco de dados quando poderia estar pagando bem mais barato por um produto melhor.
E, desculpe a sinceridade, mas se eu fosse o responsavel por um projeto cuja equipe tivesse o tipo de duvidas que voce esta tendo eu acenderia uma luz de alerta. Talvez o melhor que voce pudesse fazer agora, seria sugerir ao seu chefe a contratação de alguem com mais experiencia para este projeto.
Nesse caso, se voce esta comecando agora, vai poder aprender bastante, na pratica, com alguem que ja conhece e vai evitar cometer varios erros comuns de quem esta comecando com a plataforma Java. Se voce ja tem experiencia em outras linguagens/plataformas e está começando com Java, melhor ainda, assim você já tem uma boa noção de certo e errado e pode dividir a responsabilidade com alguem que conheça melhor as ferramentas com as quais voces vao trabalhar.
Mas se este é um projeto pequeno, sem grandes riscos, talvez fosse uma boa idéia voce experimentar todas as possibilidades pra ver a qual a equipe se adapta melhor.
[quote=YvGa]
Concordo, e alem disso, “as consultas tem que ser rapidas” é muito vago e muito pouco para valer a afirmacao “faca procedures no banco de dados e chame da aplicacao”. Isso so faz sentido em quantidades gigantes de dados ou atualizacoes em batch que poderiam demorar horas para executar. Se a aplicacao for simples isso não vale o esforço.
Sobre a afirmacao “aplicacoes grandes nao mudam de banco” eu posso dizer que ou eu sou azarado ou esta afirmacao nao é tao precisa assim. Eu trabalho com desenvolvimento ha 12 anos e estou participando da minha quarta migração de banco. Uma delas de um sistema muito grande, que já foi concluida, outra de um gigante, que esta congelada porque o sistema esta extremamente amarrado com a base (so em procedures sao mais de 2000, fora triggers e sql especifico), enquanto isso a empresa vai pagando um absurdo de licença do banco de dados quando poderia estar pagando bem mais barato por um produto melhor.
E, desculpe a sinceridade, mas se eu fosse o responsavel por um projeto cuja equipe tivesse o tipo de duvidas que voce esta tendo eu acenderia uma luz de alerta. Talvez o melhor que voce pudesse fazer agora, seria sugerir ao seu chefe a contratação de alguem com mais experiencia para este projeto.
Nesse caso, se voce esta comecando agora, vai poder aprender bastante, na pratica, com alguem que ja conhece e vai evitar cometer varios erros comuns de quem esta comecando com a plataforma Java. Se voce ja tem experiencia em outras linguagens/plataformas e está começando com Java, melhor ainda, assim você já tem uma boa noção de certo e errado e pode dividir a responsabilidade com alguem que conheça melhor as ferramentas com as quais voces vao trabalhar.
Mas se este é um projeto pequeno, sem grandes riscos, talvez fosse uma boa idéia voce experimentar todas as possibilidades pra ver a qual a equipe se adapta melhor.[/quote]
Quando eu dei a “sugestão” de fazer procedures no BD e chamar do Java a justificativa não é só performance. Como todo desenvolvimento depende das pessoas do seu time, mas de modo geral desenvolvedores Java não são bons em layout e SQL, talvez por isso o surgimento de ORM, JSF, etc.
Eu trabalho com desenvolvimento a mais ou menos o mesmo tempo que você, já trabalhei com Oracle, SQLServer, DB2, Sybase, MySQL, PostgreSQL e a única vez que trabalhei com migração de Banco foi de Fox Pro para PostgreSQL.
Entao, quanto a questao de layout até concordo. Programadores não sabem desenvolver layout e pronto, por isso existe profissional especializado nisso. Embora jsf nao seja para ajudar o programador a fazer layout de paginas.
Quanto ao SQL, eu entendi o que voce disse, eu mesmo ja vi muito disso, mas eu acho quem trabalha com sistemas de banco de dados relacionais não tem o direito de não ser bom em SQL, programador Java, que trabalha com bancos relacionais e não conhece SQL que vá jogar ping pong.
Pior é que eu sei que existem sim esses caras.
Mas é um engano achar que ferramenta ORM existe para que o programador Java não precise aprender SQL. ORM é um padrão de projeto criado para amenizar o impedance mismatch, a diferenca estrutural de um modelo de objetos e um modelo relacional. O fato de usar um, nem de longe, desobriga o programador a ter domínio sobre o SQL. Embora eu já tenha visto muita gente acreditar nisso tambem.
Talvez eu tenha sido agraciado pela sorte mesmo por ter participado de quatro migracoes, mas por isso eu aconselho a não usar qualquer recurso nativo do banco a não ser que ele ofereça ganho inquestionavel. Como escrever execucoes em batch, que alteram milhoes de registros em diversas tabelas. E mesmo assim pra mim isso é uma tristeza. Eu trabalho com uma aplicacao que roda em dois bancos diferentes, entao são duas procedures diferentes, escritas em linguagens diferentes com sintaxes bem diferentes.
Entao cuidado ao atrelar a sua aplicacao a uma base especifica.