| Autor |
Mensagem |
|
|
Eu estou usando Hibernate Annotations em algumas aplicações, e deixo aqui algumas coisas que constatei:
1. configurações com anotações realmente é mais prático nos casos simples, mas em casos de herança ou mapeamentos mais complexos, XML é mais fácil de entender.
2. o JPA é bom no geral, mas em vários detalhes, você tem que fazer configurações específicas para obter o resultado desejado. Exemplo: Pelo JPA, @AssociationOverride não funciona com @Embedded (objetos 'embedded' que possuem associações, e não apenas propriedades), mas o Hibernate permite.
3. algumas coisas só funcionam quando você usa o XML específico! Exemplo: lazy-loading de Blobs em um @Embedded, só funcionou quando configurei no HBM, tentei com todas as anotações possíveis e imagináveis e nada (provavelmente é um bug, mas o fato é que não funciona)
4. mapeamento ORM, quando vai além do 'gerado a partir do banco' (isto é, qualquer mapeamento não trivial) não é tão simples quanto parece, e diferenças entre bancos (Oracle, Postgresql, hsqldb, mysql) e entre providers (Hibernate, Toplink, OpenJPA) afetam consideravelmente o mapeamento (diferença no suporte de features como sequences, etc.). Então, essa coisa de 'apenas gere tudo a partir do banco' pode ser uma furada sem volta.
Resumindo, JPA é bom, é bom ter um padrão para funções comuns. Mas quando for fazer um projeto, faça uma escolha de tecnologia (provider) e aprenda-a profundamente, porque com certeza você vai esbarrar com bugs e peculiaridades da implementação, e só vai saber diagnosticar o problema se conhecer bem o que vai por baixo dos panos. Além disso, importantes funções de tunning de performance - como a configuração de cache, por exemplo - são 'proprietários' (específicos). Usar apenas o que é 'padrão' parece bom, mas quando o padrão nao é suficiente, se limitar a ele é simplesmente burrice.
|
 |
|
|
pcalcado wrote:
ronaldtm wrote:O engraçado é que quando se trata de qualquer coisa Java, o termo usado é 'engessado' e todo mundo odeia, enquanto que quando se fala sobre Rails, o termo usado é 'opinionated' e todo mundo adora. 
Ahm?
Calma, calma, não é nada pessoal. Na verdade, nem sequer é específico a este framework em questão.
É que às vezes eu acho engraçado que as pessoas dão piti quando se fala em estabelecer uma arquitetura 'default' para um determinado framework Java (nome de pacote padrao pra classes de visão, controllers e entidades, tem que ter tal anotação ou implementar tal interface, tem que seguir determinada convenção de nomeclatura, etc.), mas quando se trata do Rails (que possui diretórios padrão pra views, controllers e entidades, vc tem que estender determinadas classes, tem que seguir determinada convenção de nomeclatura, etc.), todo mundo acha lindo, dizem que isso vai destruir o Java, blábláblá.
De novo, não estou dizendo que esse Atena é um equivalente ao Rails pra Java (longe disso!), somente um comentário (genérico) sobre algo que eu tenho observado por aí.
|
|
|
|
|
O engraçado é que quando se trata de qualquer coisa Java, o termo usado é 'engessado' e todo mundo odeia, enquanto que quando se fala sobre Rails, o termo usado é 'opinionated' e todo mundo adora.
|
|
|
|
bzanchet wrote:Se ocorrer duas cópias na lista apontando pro mesmo filme, deveria mostrar o titulo do filme como 'teste', na segunda? Ele não muda, porque o valor é lido novamente do banco de dados.
Veja se isso resolve (não tenho a mínima idéia, só fiz a pergunta no fórum do rubyonbr ):
http://forum.divdev.railsplayground.net/forums/1/topics/179
|
|
|
|
|
Hum... alguma solução para o problema do rapaz, que faz trinta selects pra carregar uma página?
|
|
|
|
Po, sergio, tu me decepciona desse jeito, pensei que vc ia dar uma olhada no Spring, como havia me dito 
Eu não tenho certeza, mas acho que no falecido projeto Apache Avalon, as dependências eram injetadas desse jeito, usando interfaces. Mas os containers IoC 'modernos' (Spring, Pico, HiveMind) usam reflection sim, você não precisa declarar uma interface pra cada dependência. As interfaces surgem apenas como boas práticas, mas é perfeitamente possível usar classes que não estendem de interface alguma. Aliás, eu acho que os setters de dependências não deveriam sequer serem declarados em interfaces, pois estas representam na maioria das vezes funções de negócio, enquanto dependências são detalhes de implementação.
Quanto às diferentes formas de injeção de dependências, Martin Fowler escreveu um artigo interessante que explica bem três formas de injeção - por construtores, por setters e por interfaces -, que há algum tempo atrás eu traduzi para o português.
Eu lembro de ter lido em um blog no java.net (faz tempo), de uma outra forma de injeção, a getter injection (!). Essa abordagem também é bastante interessante, apesar de ser meio viajante Consistiria em declarar getters (abstratos ou que retornassem um valor default) para as dependências, que seriam sobrescritos pelo container, fazendo-os retornar as referências dos objetos injetados.
Uma grande vantagem que eu vejo nessa abordagem é que, ao contrário da setter injection (e das outras também), não haveria a necessidade de se criar métodos públicos para a injeção (como serão sobrescritos, os getters poderiam ser apenas protected), evitando 'sujar' a interface pública das classes.
Como desvantagem, eu penso que as pessoas já tem dificuldade o bastante para entender a injeção usando reflection simples, imagine usando herança com geração automática de bytecode (ainda mais 'indireto', a meu ver)! Outro ponto seria que, por essa abordagem, seria mais difícil usar o objeto sem um container (num test-case, por exemplo), já que os métodos injetores não são públicos. Você teria que estender cada classe para injetar a depenência (argh). Além disso, essa manipulação de bytecodes necessitaria de um framework adicional como a CGlib, BCEL ou Javassist, aumentando o número mínimo de jars empacotados junto da sua aplicação.
Bom, mas já estou viajando demais.... voltando à pergunta: dá pra alterar atributos privados via reflection, sem que o security manager do java reclame (sinceramente eu nunca tentei)? Via policies talvez... Mas isso seria recomendável?
Como eu já disse (e outras pessoas também) , não é preciso criar uma interface para injeção de dependências, pelo menos nos containers de Dependency Injection mais usados por aí. O uso de interfaces já foi utilizado no passado, mas acho que a morte desse projeto dá uma indicação de que a abordagem não foi muito bem aceita (também, credo, uma interface pra cada dependência???). Acessar diretamente atributos privados é perigoso, quebra completamente o encapsulamento e expõe suas classes a bugs indetectáveis (por exemplo, se você declarar um atributo privado que não deve ser injetado, que é um caso bastante comum, creio). Sobrescrever getters tem vantagens, mas não acho que elas acrescentem valor suficiente para ignorar as desvantagens.
Eu continuo 'partidário' da injeção via setters construtores, que não são tão invasivas ao código, não requerem malabarismos muito grandes (só reflection simples), não têm problemas com security managers, e são relativamente fáceis de compreender.
|
|
|
|
http://forum.java.sun.com/thread.jspa?threadID=533029&messageID=2572018
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4784692
|
|
|
|
A interface Collection representa o conceito mais abstrato, que é uma coleção de objetos. Não se pode assumir nada sobre a ordenação, indexação ou duplicação de elementos.
Já a interface List adiciona posicionamento aos elementos, isto é, cada elemento possui um índice numérico sequencial. Seria uma representação abstrata de um array, com a capacidade (opcional) de se adicionar e remover elementos. Uma classe que implemente esta interface deve implementar, além dos métodos da Collection, os métodos extras declarados na interface List.
A interface Set é um caso onde a única alteração é conceitual, isto é, não é adicionado nenhum método além dos já declarados na Collection. O que a interface faz é expressar um contrato, que é o de não haver elementos iguais (equals()) no conjunto.
E a interface SortedSet estende a Set, adicionando o conceito de ordenação natural dos elementos (Comparable/Comparator), mas ainda assim sem índices.
A interface List é a única que fornece métodos de acesso aleatório (indexado), por isso é a única que possui os métodos get(int) e set(int). Já as outras, permitem apenas o acesso através de um Iterator, que abstrai o percorrimento da estrutura de dados interna.
Tetsuo
|
|
|
|
cv wrote:Chamar /usr/bin/ping, talvez?
É, ou isso
|
|
|
|
Eu estava tentando fazer isso um tempo atrás...
Não dá. O ping requer a criação de um pacote ICMP, que por sua vez requer acesso a um RAW_SOCKET, que por sua vez, requer acesso root ao sistema (ele permite a criação de sniffers, por isso a restrição), na maioria dos Unix.
Provavelmente por isso, o Java não tem suporte ao protocolo, apenas a protocolos mais alto-nível como TCP e UDP.
Pra fazer isso, use alguma biblioteca C pra rede em baixo-nível (pcap/winpcap, por exemplo) e chame via JNI, creio que é o único jeito.
Tetsuo
|
|
|
|
skill_ufmt wrote:
ronaldtm wrote: Dizer que 'só uso OO' ou 'só uso procedures' é limitante, e pode levar a pensamentos extremistas como os do colega skull. XD
Tetsuo
é Skill não esculaxa também ehehe
Minha possição extremista EXCLUSIVAMENTE neste tópico parte do princípio de que para que criariam OO se é para usarmos OO-Relacional? ntão deixava como estava, concorda?
Agora se criaram é por que alguma coisa no outro modo não estava dando certo.
Enfim se criaram OO vamos usar OO ou ficar no PE, e não OOR, entende?
Tá é extremista sim, mas fazer o que antes não tivessem criado ehehe
Calma, calma, eu tava brincando!
|
|
|
|
pcalcado wrote:A conclusão que tiro é que podemos estar falando da mesma coisa em escopo diferente.
É, eu estava pensando nisso também, o problema é o 'mismatch' da língua, a opinião não é tão diferente assim (é um pouco, mas cada um deve ter a sua mesmo )
Bom, vou deixar você trabalhar agora  (afe, ninguém merece...)
Tetsuo
|
|
|
|
E eu, que tinha prometido pra mim mesmo que não ia mais entrar nessas discussões sem fim... -sigh--
pcalcado wrote:Quer dizer que as habilidades das pessoas variam?
Não?
pcalcado wrote:Bom, programar proceduralmente também requer habilidade e conhecimento, existem diversos livros sobre boas práticas, Yourdon, Page-Jones e tantos outros sobre Análise Essencial e Projeto Estruturado dão uma idéia que mesmo os sistemas procedurais feitos hoje (e ontem) não estão nas boas práticas, e se você considerar que as pessoas programam com ele há mais tempo, é preocupante.
Se a pessoa sabe programar estruturada e quer passar para OO, uma abordagem assim (mista) pode ser funcional, mas eu não usaria em projetos muito sérios (contrate novas pessoas ou treine os antigos antes de começar, pelo menos tenha um coach disponível!).
Se a pessoa sabe programar OO dificilmente vai ter problemas num modelo de objetos puro, mas em tecnologias como Java vai acabar limitado (e xingando muito), logo uma abordagem com pequenos toques procedurais se faz necessário pelas limitações impodtas. Note, entretanto, que programar de maneira OO não implica programar numa linguagem oo, e vice-versa. "Eu posso programar FORTRAN em qualquer linguagem".
Se a pessoa sabe estruturada e não quer usar OO... a menos que não haja escolha deixe o cara em paz e atualize o ambiente que ele usa.
Exato. O problema é que muito pouca gente sabe programar OO. Muitos sabem Java, muitos sabem usar Struts (argh), mas poucos conseguiriam construir um Struts ou um WebWork (hum... não é um exemplo legal, já existem frameworks MVC demais por aí, dá pra copiar na boa... whatever).
É aquela coisa, o cara fala: '- Essa classe chama essa, essa classe chama essa. Aqui, eu usei o páterni Obisérver com Injeção de Dependente.'
Tá, você é bom, e modéstia a parte, eu sou bom . Mas e a média do mercado?
Exemplo real: no meu trabalho, minha equipe está fazendo um sistema (obs.: não é web) para um banco. Eu criei um framework que integra várias tecnologias, se comunica com vários outros sistemas, faz o controle de fluxo, lifecycle, recursos, encapsula os detalhes da tecnologia (de infra-estrutura) utilizada, etc. Lá até tem uns caras bons (por sorte, peguei um com bom potencial pra treinar), mas a maioria não é exatamente de 'programadores hardcore'. Eles entendem de negócio, conseguem fazer loops e ifs em java, mas vai perguntar pra eles a diferença entre composição e herança! Pode até ser que algum responda, mas vai ser uma resposta decorada do livro. Isso não é exatamente condenável, nem todo mumdo pode ou quer passar as madrugadas estudando pra aprimorar essa habilidade especificamente.
Por isso, fizemos com que as 'transações de negócio' ficassem o mais simples possível. Basta estender uma classe (eu fiz uma interface também, tá, não ouse compará-lo ao Struts! ), implementar um método e registrar a classe em um XML. Já estão lá os métodos auxiliares, as referências para os recursos necessários, etc. A programação, neste nível, é procedural. Por trás, tem todo o projeto OO, com as interfaces bem definidas, hooks pra pontos de extensão, classes-base pra facilitar a implementação. Foi um misto de objeto-procedural que aproveitou o melhor dos dois mundos, ao invés de se limitar a um deles.
pcalcado wrote:
ronaldtm wrote:
2. Eu não vou, nem quero, ficar na manutenção do sistema, anos depois.
Isso tem a ver com o item 1? Bom, se você faz um sistema ruim em OO, procedural ou BASIC ele vai ser ruim de manter até por você...não sei exatamente o que você quis dizer aqui.
Eu só estava continuando a idéia do ítem 1. Não quis dizer que é mais fácil manter um programa procedural (aliás, deve ser bem mais difícil se o nível de complexidade for alto).
OO foi criada para facilitar o gerenciamento da complexidade (na verdade, para dar ferramentas pra isso). Nas partes mais complexas do sistema, bastante OO cai muito bem. Nas partes do sistema que vão ser mantidas por programadores 'não tão programadores', a abordagem procedural é mais apropriada, porque é mais simples se mantida isolada e é mais fácil pra eles entenderem.
pcalcado wrote:O que é purismo?
Usar as ferramentas do paradigma como elas foram concebidas? Boas práticas? Técnicas avançadas?
Se seu sistema é simples, ele não precisa mais que o bê-a-bá da OO.
Se ele for complexo, a regra muda.
Se ele for muito simples, faça em shell script com GTK, fica bem legal
Purismo é achar que ter um 'get' no código é um sacrilégio e o cara tem que ser queimado na fogueira!
Brincadeira (duh). O purismo que eu falo é achar inaceitável o fato de termos que fazer pequenas gambiarras não-OO, como você mesmo falou, e alguns outros casos, como esse do exemplo (partes do sistema feitas para serem procedurais).
pcalcado wrote:Sim, eu posso programar com tudo isso mesmo usando um SGBD. Basta eu fazer um mapeamento condizente e bem feito. Ok, certas coisas vão ser belas gambiarras, mas passar entre paradigmas sempre implica em gambiarras (alguém mencionou JNI?), e esse é um dos meus pontos quanto misturar paradigmas em um único sistema (note que não falo de subsistemas se comunicando).
Certo, mas não é OO 'puro', você concorda, certo? E é isso que eu acho isso perfeitamente aceitável, por isso não concordei com o 'se vai programar OO, programe só OO, se vai programar procedural, programe só procedural'.
pcalcado wrote:O Domain Model é a essência de um sistema. Se você vai mais que ler o conteúdo de um campo de texto para colocar num INSERT, vale muito a pena um bem construído.
Eu estava me referindo ao padrão Domain Model (no Fowler, Business Object, no Core). É nesse sentido que você está falando?
pcalcado wrote:O grande ponto é: escolhi a tecnologia errada. java e servlets para fazer algo tão simples é um overkill. Pense nisso 
Tá me chamando de programador ASP? Precisava me insultar assim?
O que eu estou tentando defender é exatamente 'the right tool for the job'. Dizer que 'só uso OO' ou 'só uso procedures' é limitante, e pode levar a pensamentos extremistas como os do colega skull. XD
Tetsuo
|
|
|
|
skill_ufmt wrote:
ronaldtm wrote:... e não dá pra programar 'puramente OO' ...
Tetsuo
NÃO? vige maria santa, agora ferrou legal, se num da para programar OO, então vamos parar com ela
vamos voltar aos procedimentos, ou quem sabe a boa época das válvulas
Você por acaso leu o que eu escrevi? -sigh--
|
|
|
|
pcalcado wrote: Usamos as ferramentas certas para a ocasião certa
Isso! 
|
|
|
|
|
|