Estou desenvolvendo um projeto em que estou dividndo tudo em 3 camadas, caso as procedures puderem ser consideradas uma camada, diria que são 4.
Mas volta e meia na hora de dar manutenção tenho que ir em 4 lugares diferentes para adicionar ou remover um único campo de uma entidade.
Exemplo das minhas classes
EntidadeVO - VO
EntidadeController - BO
EntidadeDAO - DAO
O que vcs acham considerando que não haverá mudanças no banco de dados, há necessidade da DAO e as procedures, já estou cansado de editar procedures, ainda mais pq segui o conceito de não deixar lógica nas procedures, o que acaba aumentando mto o numero de procedures. Não sei se o que mais me incomoda são as procedures ou a DAO, acho que há redundância, excesso de desacoplamento.
Me parece que perdi produtividade ao invés de ganhá-la, estou incomodado de usar procedures para toda chamada ao banco, e com a DAO que não faz mais nada do que a execução da chamada ao banco a essas mesmas procedures.
Estou exagerando? estou em um bom caminho? devo respirar e tentar enxergar as vantagens?
João, não gosto muito de deixar a lógica de negocio dentro do banco, tenho que ficar indo a mil lugares para dar manutenção ou expandindo ela.
se você usar hibernate (ou algo do tipo) e generics você consegue ter seu sistema inteiro com apenas 1 (ou poucos) DAO, o que realmente aumentaria sua produtividade.
lembre-se que o que vai diz se você tem um bom sistema é que suas partes tenham suas funções bem definidas, logo usar DAO é interessante por que somos sempre tentados a dar mais responsabilidades do que devemos a certos objetos, deixe a persistência com quem deve fazê-la.
Olha desde o momento em que aprendi a usar DAO, nunca mais fiquei sem usar o mesmo pelos benefícios que o mesmo nos proporciona. Agora vc me pergunta: pq? Por exemplo, hoje vc diz que não irão mudar de banco mas, pode ser que em um futuro próximo e até mesmo longinquo vc possa querer acessar outra base(xml, arquivo etc.) que não a atual. Aí vc se vc estiver usando o DAO de uma maneira mais eficiente e desacoplada(usando Factory ou IoC), vai perceber o quanto esta decisão te ajudará. Outra coisa, o DAO é usado para abstrair a forma pela qual vc obtém os dados de sua aplicação, deixando sua classe de negócios responsável pelo que realmente interessa a ela: negócios.
Uma coisa que me incomodou em sua arquitetura: vc usa o controlador como objeto de negócios também ou entendi mau?! Se sim, te aconselho a rever esta idéia pois, ele está acumulando responsabilidades e sua aplicação está ficando menos, digamos, extensível com isso.
