http://www.macoratti.net/07/12/net_linq.htm
Existem cinco formas nas quais poderemos utilizar o LINQ.
LINQ to SQL
LINQ to XML
LINQ to Objects
LINQ to DataSet
LINQ to Entities
Language Integrated Query é uma tendencia ou JPA já é o suficiente para o Java ?
Eu desconheço por completo, embora já tenha ouvido falar muito sobre Linq.
Quais as vantagens do Linq sobre um ORM nos moldes do JPA?
É bem mais prático de escrever e infinitamente mais legível do que Criteria. E ao contrário do HQL, a expressão permite refatoracao, por ser direto da linguagem e não uma string a ser interpretada.
Tendencia? Isso existe há uma década no C#. Depois que finalmente Java adotou lambda expressions, a Oracle poderia sim investir em algo parecido para JPA. Fora banco de dados, acredito que tenha algumas situações que vocês já possam tirar algum proveito de lambda expressions do Java a partir da versão que implementaram isso.
Sobre o que é suficiente. Pra mim tanto em Java quanto .NET, para bd relacional SQL é o suficiente.
Não é a Oracle que define isso, é o JCP, depende da comunidade Java abraçar. Um caminho seria fazer um fork do OpenJDK, implementar e submeter a sugestão.
Entendi, mas acredito que tenha que vir algum investimento/patrocinio pra ninguém trabalhar de graça.
Sim, em algum ponto isso depende de um grande player abraçar a ideia, tipo uma Apache ou Eclipse Foundation.
Pessoalmente gosto da idéia de trabalhar com banco de dados usando diretamente as estruturas de dados nativas da linguagem, ao invés de strings, objetos ResultSet, frameworks ORM.
Mas não sei se a Oracle tem planos de fazer Java menos OO.
Eu gostaria se eles fizessem algo no java para gerar JSON e XML.
É bem mais simples, o que pode ser uma vantagem ou não, dependendo do seu ramo de atuação.
Com relação a performance, não creio que LINQ resolve o problema de N+1 queries.
Você fala tipo Codable no Swift 4?
Acho que esse não é o foco do LINQ, mas sem dúvida seria bom ter no Java também.
Quem desenvolve com C# não tem nenhuma reclamação da linguagem?
Quem desenvolve em RoR não tem reclamações?
Quem desenvolve em Go também não?
Tudo, absolutamente tudo, sempre terá quem goste e quem odeie.
Entre os que gostam, sempre terá coisas que desagradam e coisas que são motivos de glórias.
Se você acha que o active record é a melhor coisa do mundo, por que insiste em algo que não tem isso?
Se Ling e C# são maravilhosos, por que perde tempo com o java?
Se Kotlin resolve todos os problemas que o java tem, então foca no kotlin.
Qual a razão de insistir em uma linguagem falida, pesada, lenta e cheia de problemas, com atualização tão lenta?
Enquanto se olhar para uma linguagem ou IDE sem ser pelo viés de que aquilo é uma ferramenta e é voltada para N coisas, feitas de Y maneiras e não serve para outras X e não faz de Z formas, a ______________ (insira ali sua linguagem mais odiada) vai seguir sendo ruim para você.
É o mesmo que querer que um martelo corte a grama: pode funcionar, mas vale a pena tentar?
Dias atrás eu respondi uma questão sobre performance de banco de dados e se bancos NoSQL seriam viáveis para uma necessidade específica.
Eu respondi que, se fosse eu, migrava tudo para MongoDB (que é o NoSQL que mais conheço, embora não seja especialista).
A negativa do sujeito que postou foi baseada em algumas características dos bancos de dados relacionais, algo como “se eu tenho uma publicação publicada por A e compartilhada por B, caso A edite, como vou refletir em B?”. É óbvio que ele só estava pensando no modelo estruturado, onde há tabelas e chaves estrangeiras, primárias e etc.
Se ele conhecesse um pouquinho só do modelo NoSQL, veria que isso é muito mais simples e que as chaves são desnecessárias nesse caso.
O que quero dizer é que, quando se quer desenvolver em uma linguagem, deve-se olhar o mundo pelo modo de ver daquela linguagem.
É como aprender um idioma, como o coreano, não basta decorar significados isolados e frases prontas, é preciso pensar em coreano para ser fluente.
Não curto nada que não me deixe escrever SQL diretamente, mas pra galera que usa é possível resolver N+1 queries com Fetch por exemplo, no caso do NHibernate, pois depende da implentação de cada ferramenta. Claro que na prática é uma zona, a maioria escreve sem se preocupar com o que de fato está sendo gerado. LINQ é expressivamente ótimo, mas só gosto de usar para objetos em memória.
Qual motivo pra não curtir se referir a determinada informação no banco da maneira mais expressiva do ponto de vista do seu programa, ou seja, usando uma estrutura de dados nativa da própria linguagem?
Entendo o argumento de que não compensa usar para aplicações simples (CRUD), e de fato, string é a forma mais expressiva quando se escreve queries avulsas no terminal, mas no caso de uma aplicação mais complexa, não da pra ser tudo baseado em string e ResultSet né?
@rmendes08 estamos falando de LINQ.
tem um exemplo disso ? que linguagem que trabalha dessa maneira ?
Não entendi, ou estou por fora do que você está falando. Trabalho com bd relacional, uso SQL e PL/SQL diretamente. Apesar de conhecer e ter que lidar com isso, fujo de query de ORM, seja LINQ to NHibernate, QueryOver, HQL, Criteria, etc. Já outras formas estou por fora, do que estaria falando?
Eu prefiro o termo ‘integrado’ em vez de ‘direto’.
PL/SQL tem uma linguagem de consulta integrada chamada SQL.
Estou dizendo não vejo motivo pra não querer uma linguagem de consulta integrada na sua linguagem de propósito geral também.
Ter uma linguagem de consulta integrada na linguagem é uma forma mais expressiva de trabalhar com banco de dados do que qualquer framework ORM.
Estava pensando em LINQ to SQL.
Sobre Linq to SQL, nunca mais vi ninguém usando para novas aplicações, pra mim já tinha sido descontinuado. É bem mais limitado do que NHibernate ou Entity Framework.
Se está querendo dizer o que citou sobre o Swift 4, isso ai estou por fora mesmo, nunca trabalhei com iOS.
Alguns pontos: O Linq to SQL (que pode ser confundido com o linq (no linq existe muitas divisões como linq to sql, linq to object, linq to xml) que gera SQL no Entity Framework) é um camada de persistência, muito boa, não é descontinuada, e não é que ela não é muito utilizada, a grande questão dessa camada é que só funciona com SqlServer e por isso a maioria das pessoas preferem utilizar uma ORM que possa trocar o banco e a aplicação funcionar do mesmo jeito é mais por essa limitação, mas, sinceridade é muito rapido as operações CRUD e as consultas e integração com StoredProcedure