| Autor |
Mensagem |
|
|
A padronização das APIs não significa que as redes sociais precisarão ser todas da mesma forma. Cabe a quem for trabalhar na JSR reconhecer os pontos onde estão essas diferenças e criar uma API que suporte as peculiaridades de cada uma.
Isso daria um bom artigo para a MundoJ... Alguém se habilita?
|
 |
|
|
Depende do objetivo da sua aplicação! A arquitetura não é boa ou ruim simplesmente, ela é adequada ou não de acordo com as necessidades da aplicação.... 
Acho que essa sua resposta saiu um pouco do escopo do tópico, não acha? Sugiro que você crie um novo tópico que tenho certeza que muitas pessoas terão o prazer em te ajudar. Ah, e forneça mais informações sobre os requisitos da aplicação!
|
|
|
|
Almeidaah wrote:
FabricioPJ wrote:Algumas idéias que tive foram:
1) Escrevendo queries otimizadas
2) SQL avançado
3) Algum assunto relacionado a PL/SQL
Não sei se encaixa do jeito que você falou, mas se não der, sem problema. Eu ajudo quando puder, aqui pelo fórum mesmo
Fabrício, tenta montar um artigo que junte a integração de sql com alguma aplicação web J2EE por exemplo, e aí você detalha as suas queries, destacando pontos importantes, mais sem perder o foco na linguagem da aplicação. 
Uma boa sugestão! Seria interessante que o artigo também ressaltasse questões relativas a como a conexão deve ser estabelecida (como o tipo de isolamento), como os dados devem ser recuperados e etc...
|
|
|
|
Mais um componente do Esfinge Framework liberado para download e com documentação completa no site! O Esfinge Comparison é um framework para realizar a comparação entre dois objetos da mesma classe, retornando as diferenças entre suas propriedades. Esse framework pode ser utilizado para recuperar a diferença entre duas versões da mesma entidade para questões de registro de auditoria (logging), para ressaltar as mudanças em um formulário, dentre outros possíveis usos? A grande inovação é que o algoritmo de comparação pode ser totalmente customizado com a adição de anotações que configuram como a comparação para cada propriedade deve ser realizada.
Dentre as funcionalidades do framework pode-se destacar a comparação de propriedades com objetos compostos, a comparação de listas, tratamento de referências circulares e a integração com as anotações do JPA. O framework ainda suporta extensões para o mecanismo de leitura de metadados, nas camadas de comparação e para a criação de novas anotações que customizam o algoritmo de comparação de uma propriedade.
Vale a pena conferir!
|
|
|
|
FabricioPJ wrote:Há alguma possibilidade da revista publicar algum artigo relacionado a banco de dados puro, mais especificamente SQL/Performance de queries? Se sim, teria prazer em elaborar algum.
Infelizmente esse não é o foco da revista, porém se no escopo do artigo estiver a interface da persistência com a aplicação, daí acho que conseguimos encaixar sim!
|
|
|
|
É isso aí pessoal! Estou gostando das sugestões e já recebi até alguns emails...
Estruturem direitinho a proposta de vocês e enviem apra mim!
|
|
|
|
rogelgarcia wrote:
Concordo com o asaudate sobre a criação de métodos personalizados. Pode ser interessante que eu crie meu próprio método e outros eu deixo para serem implementados pelo framework. Nesse caso, acho que uma classe abstrata seria uma boa opção. Existirão alguns problemas para criar a classe concreta em Runtime no caso da classe abstrata que não ocorrem para a interface. Mas framework é para isso mesmo, resolver problemas.
Na verdade penso em você definir uma interface e uma implementação. Daí todas as interfaces que estenderem aquela sua irão adquirir aquela implementação para o método.
rogelgarcia wrote:
Cuidado com o uso excessivo de anotações.
Pode deixar que essa é minha área de pesquisa e já orientei inclusive trabalhos que focavam na legibilidde de código anotado. Em relação a isso tenho duas considerações:
- As anotações costumam ser mais confusas em classes, onde elas se misturam com código. Em interfaces onde tudo é mais declarativo, elas acabam atrapalhando menos.
- Grande parte das anotações serão nos parâmetros para dizer ao framework com interpreta-los. Apesar de haverem muitas possibilidades, acredito que haverá no máximo duas anotações em um parâmetro.
- As anotações para definir termos de domínio tem o potencial de gerar um bom volume em anotações. Apesar disso, a idéia é que os termos de domínio deixem a definição dos métodos mais legível, não precisando que as pessoas recorram a definição deles para entender.
rogelgarcia wrote:
Sobre a nomeclatura, acho que QueryBuilder não é um nome adequado. Um query builder deveria ser um construtor de queries, possivelmente usando algum builder pattern (como method chainning). No caso o framework é um construtor de DAOs.
Na verdade quando o framework começou a ser criado a idéia dele era penas a criação de consultas, porém depois decidiu-se incorporar o DAO também... Daí o nome ficou!
Na verdade existe sim um builder por trás do framework...
rogelgarcia wrote:
Pense em escalabilidade. Para exemplos acadêmicos é fácil fazer um DAO através da interface apenas com um padrão de nomeclatura. Mas e para queries complexas? E se eu quiser fazer algum join? E se eu quiser buscar alguma coleção? Ou uma cláusula where que contenha OR?
É perigoso ter métodos com nomes muito longos ou tenha que utilizar muitas anotações para conseguir fazer a query. Acho que ficaria menos intuitivo do que eu mesmo escrever a query. Se a API servir apenas para situações triviais um método getByExample resolveria grande parte das situações.
Na verdade o framework suporta muitas das situações que você citou como OR, join e inclusive queries onde um parâmetro precisa ser ignorado quando for nulo. Acredito que o Esfinge QueryBuilder consegue deixar algumas coisas bem transparentes e dar opções para quem cria os métodos, como o uso de termos de domínio, alternativas entre colocar coisas no nome do método ou como anotação do parâmetro e etc... Dê uma olhada nos tutoriais que o framework suporta muito mais do que você imagina.
A idéia do framework não é servir para 100% das consultas, mas poupar tempo no desenvolvimento de pelo menos uns 90% delas...
O framework disponibiliza um método chamado queryByExample() na interface repository que funciona como você falou, porém ele é limitado no sentido de que não é possível definir outros tipos de comparação (maior, contains), não é possível definir entre and/or e etc...
Estamos sempre trabalhando para deixar sempre a definição das consultas mais simples. Estamos trabalhando em uma funcionalidade que irá permitir passar JavaBeans como parâmetros, sendo que os parâmetros serão buscados de suas propriedades.
rogelgarcia wrote:
Bem vindo ao mundo dos criadores de framework.. kkkk 
Já estou nesse mundo a um certo tempo! Eu sei que as críticas e sugestões construtivas, como vocês estão dando, são muito importantes para evoluir o framework de acordo com necessidades reais. Porém, é preciso saber filtrar e ignorar quem simplesmente nem lê a documentação do framework e dispara algumas críticas sem muito sentido...
|
|
|
|
cheio_de_duvidas wrote:Então você só declara assinaturas de métodos de "pesquisa" ou "busca" (sempre anotando-os) porque os de edição o framework já gera automaticamente pra você até baseado nos relacionamentos entre as classes como coloquei a agregação do Motor dentro do Carro no exemplo ??
Algumas considerações:
- Os métodos que você chama de pesquisa e busca não necessariamente precisam ser anotados
- Os outros métodos CRUD ele adiciona na sua interface se ela estender Repository
- A questão da agregação será persistido ou não dependendo de como você anotar as suas classes com as anotações do JPA
|
|
|
|
Uma coisa é a JDK em que o Eclipse está rodando e outra é a que ele está usando para compilar.
Acho que o problema é que o projeto deve ainda estar configurado para a máquina virtual anterior.
Veja como mudar:
1) Entre no menu Window>Preferences
2) Escolha Java>Instaled JREs
3) Adicione sua nova JDK
Depois se necessário, entre nas propriedades dos projetos e veja se precisa mudar lá também!
|
|
|
|
Caros amigos do GUJ!
Muitas pessoas me perguntam sobre como funciona para enviar um artigo para a revista MundoJ. O primeiro passo é encaminhar para artigos@mundoj.com.br uma descrição do tema que pretende abordar em seu artigo. Sugiro que dêem uma olhada nas edições anteriores da revista para ver se um artigo com o mesmo tema já não foi publicado. Outra dica é pesquisar na internet o que já existe a respeito do tema. Procure dar algum diferencial ao seu artigo: um exemplo mais completo, uma explicação mais profunda dos conceitos, comparação com outras tecnologias e etc...
Aproveito a oportunidade para convidar os desenvovledores da comunidade GUJ para submeter propostas de artigos a revista. Aceitamos artigos com as seguintes temáticas:
- Arquitetura de Software
- Design de Software
- Linguagem Java e APIs Básicas
- Aplicações Corporativas (Java EE e etc...)
- Desenvolvimento Web
- Linguagens que executam na JVM
- Aplicações Móveis (Java ME, Android ...)
- Métodos Ágeis
- Persistência de Dados
- Testes de Software
- Ferramentas de Desenvolvimento
- Frameworks
- Certificações
- E outros temas relacionados a desenvolvimento de software...
Ficarei aguardando a sua idéia!
|
|
|
|
Roger75 wrote:Esse framework exige qual versão mínima de Java/JavaEE? Na empresa usamos Java6 e JavaEE 5, será que é compatível?
Certamente! Ele é compatível com JPA 1, então no seu ambiente vai funcionar sem problemas!
|
|
|
|
fabioEM wrote:Acho que vai demorar para começar, uns 5 anos ainda para vermos algo.
Escute o episódio do Grok Podcast sobre NoSQL que são citados vários casos de sucesso.
|
|
|
|
JMARQ wrote:Como configurá-lo para testar?
Entre no site do framework: http://esfinge.sf.net e no menu documentação, a parte "Funcionalidades Básicas do QueryBuilder" explica detalhadamente como configurar. Veja lá! Não é complicado!
Se tiver alguma dúvida ou dificuldade é só colocar no forum do projeto!
|
|
|
|
cheio_de_duvidas wrote:Eduardo , então basta declarar java beans (sem métodos) e seus relacionamentos que o framework gera um CRUD ?
Por ex. para
Obrigado desde já!
Na verdade para que o framework implemente o CRUD você precisa que suas classes sejam mapeadas para o banco de dados usando JPA. No caso, você precisaria pelo menos de anotar as classes com @Entity e ter um campo com @Id.
Porém a grande vantagem do framework é gerar as consultas a partir da assintatura de métodos de uma interface. Exemplo:
List<Carro> getCarroByMotorPotencia(double potencia);
List<Carro> getCarroByPneu1MarcaOrderByMotorPotencia(String marca);
Só a declaração do método seria suficiente para o framework!
|
|
|
|
doravan wrote:Por que reinventar a roda se você pode focar no design do carro e no motor?
http://www.hibernate.org/
Acho muito legal a sua inciativa, é assim que nascem novos frameworks de persistência. Mas ferramentas open-source já consolidadas estão aí afora para evitar retrabalhos com a camada de persistência.
Algo novo seria uma abstração de regras de negócio, já que a abstração da camada de dados está praticamente mega-consolidada.
Nenhuma roda foi reinventada! O Esfinge QueryBuilder funciona em cima do JPA (podendo-se utilizar o Hibernate ou outra implementação). Ele economiza o código que você precisaria criar para a geração de consultas, fazendo isso interpretando a assinatura de um método de uma interface. Além disso a idéia é que o Esfinge QueryBuider forneça uma funcionalidade idêntica para bancos de dados não-relacionais, fornecendo inclusive uma camada de abstração a alternativa de persistênca adotada, o que está fora do escopo do Hibernate e frameworks de mapeamento.
Por dizer isso tenho certeza que não leu a documentação do framework no site. Gostaria muito que desse uma olhada para ver se muda de idéia!
|
|
|
|