Eis uma dúvida que tenho. O que é melhor? O que abre mais tua mente a abstrair? Faz-se incrementalmente? A pergunta principal é: Qual das opções você acha melhor? E Por quê?
Prefiro mil vezes criar o modelo de classes e deixar o framework cuidar do banco de dados pra mim. Mas só tenho feito isso com meus projetos pessoais, porque no local onde trabalho atualmente precisamos iniciar a modelagem do sistema pelo modelo E/R e depois gerar as classes.
Olá, tbm prefiro a abordagem de criar as classes e deixar o framework de persistencia cuidar do banco. Na verdade quando estou modelando as classes esqueço que tenha um banco de dados;
Como você está (teoricamente) desenvolvendo um sistema orientado a objetos, nada mais natural do que você pensar em objetos quando estar desenvolvendo, e não em tabelas. Creio que é a maneira mais fácil.
Mas como disse o tnaires, muitas empresas ‘exigem’ (até mesmo os clientes) que se faça primeiro a modelagem do banco.
[]´s
Sempre que possivel comece pelos objetos, eles eh que vao determinar o comportamento do sistema. Depois crie um lugar para armazena-los. Eu faço o modelo do banco incrementalmente, depois dos objetos implementados e testados.
Bom isso varia em função da metodologia que se estiver utilizando, por exemplo,no OPENUP o diagrama de classes vem antes de qualquer coisa na fase de elaboração, sendo que o MER vem somente depois de modelada as funcionalidades da iteração, dessa forma tanto o diagrama de classe como o MER vão evoluindo incrementalmente. Mas por outro lado se você estiver usando JDBC você não tem framework o que teoricamente não faria diferença entre um e outro sendo que no final das contas você vai mapear a classe para a tabela mesmo. Mas ainda sim prefiro primeiro pensar em classes e objetos, para só depois pensar em tabelas.
É, nesse caso não há como escapar, tem que criar o modelo físico na mão - preferencialmente após a criação do modelo de classes. Mas tendo uma ferramenta como o Hibernate, que pode criar o modelo de dados incrementalmente, podemos esquecer (quase) completamente que há um banco por trás de tudo.
Nossa, se na realidade do mundo corporativo viesse a UML antes, meu Deus, eu estaria nas nuvens!
Amigo, aonde você leu isso no OpenUP?
Já leram o beabá?
http://www.agiledata.org/essays/culturalImpedanceMismatch.html
Esse aqui é o mais importante:
http://www.agiledata.org/essays/drivingForces.html
Resumo: Projetos OO são os objetos que dirigem a construção do seu modelo de banco. Cuidado com o DBAzinhos que querem manter seus empregos. Eles ficam com aquelas masturbações mentais do tipo “ah… esse indice tá errado… ah… esse relacionamento deve ser trocado… ah… isso não tá normalizado…”… Nesses dias com Hibernate, CouchDB, Caching de Objetos e outras coisitas mais os DBAs perderam bastante “poder”. Já faz uns bons 5 anos que não sinto falta deles nos meus projetos. Melhorar a performance do banco é algo que qualquer programador deve saber…
Amigo, aonde você leu isso no OpenUP? [/quote]
Se tu achar um diagrama MER na fase de elaboração te dou um prêmio…
http://epf.eclipse.org/wikis/openuppt/
E mais outra não quer dizer que não pode, mas a metodologia não diz.
[quote=laudenpower]
Se tu achar um diagrama MER na fase de elaboração te dou um prêmio…
http://epf.eclipse.org/wikis/openuppt/[/quote]
Se você achar um MER em todo o OpenUp EU TE DOU UM PRÊMIO.
Pensando no Uncle Bob “Aquilo que matou o RUP vai matar o Agile também”, vou blogar sobre isso também…
"
[quote=marcosalex]
O maior problema que vejo é que o Hibernate nem sempre consegue gerar as querys mais otimizadas e ainda dá muito perda de performance se comparado ao SQL “puro”. Relatórios complexos, por exemplo, ainda sou obrigado a criar uma query SQL otimizada.[/quote]
Eu nunca tive problemas de performance com o Hibernate, a perda em relacao ao JDBC puro nao eh tao grande. Agora em relatorios mais complexos eu concordo com vc, eu uso bastante sql direto, mais pela simplicidade do sql do que pela performance, mas uso.
Essa eh uma coisa que me irrita profundamente, eu trabalho atualmente numa empresa que nao utiliza o processo agil, mas pensa que utiliza. Os gerentes leem meia duzia de artigos, fazem uma reuniao por dia pra controlar o trabalho dos desenvolvedores e dizem que isso é scrum. Pra se ter uma ideia, testes unitarios nao sao obrigatorios, o progrmador que quiser faz. Seria hilario se eu nao estivesse bem no meio disso tudo.
Nao preciso nem dizer que muitos dos conceitos pregados pelas metodologias ageis fazem a empresa inteira arregalar os olhos de espanto, como se o que eu estivesse dizendo fosse algo absurdo, de outro mundo. Teste primeiro? pra que se tem equipe de teste? Modelar no código? Isso faz eles cairem da cadeira, tamanho o espanto. E nao adianta mostrar que escrever uma classe no eclipse e fazer a reversa, por numa moldura banhada a ouro e pendurar na sala deles é mais rapido que diagramar com qualquer ferramenta.
E quando falha o projeto de quem é a culpa? Esse tal de scrum ai que nao presta.
"
Eu não tenho o habito de usar uma ferramenta pra gerar o modelo relacional, mas tenho o hábito de desenhar o modelo relacional a partir da modelagem OO. Tem mesmo muitas empresas que exigem o modelo do banco antes, o que é péssimo e como já disseram aí parece ser mais uma artimanha pra segurar empregos de DBAs.
"
Nao creio que seja artimanha, é só a forma de trabalhar que é diferente, dando mais importancia aos dados do que a regra. Mas é uma forma que tem dado certo, nao pra condenar totalmente. E enquanto as metodologias ageis nao provarem em larga escala que sao mais rentaveis isso nao vai mudar.
O que eu nao suporto é quando se assume o caos como metodologia e pensa que esta sendo agil.
Quanto aos dbas, um bom dba é importante em aplicacoes grandes, mas ele deve trabalhar em conjunto com os desenvolvedores e se adequar a agilidade da equipe, nao se comportar como a estrela da companhia, como acontece frequentemente.
"
Chegando bem atrasado, me espanta ver gente reclamando que não usa Hibernate porque é mais lento que o JDBC puro, sendo que a maioria parar 95% do que se desenvolve hoje em dia isso não faz a menor diferença.