Quais são os benefícios de usar a abstração de banco de dados pelo ORM? [fechadas]

19

Estou começando a usar o ORM recomendado pela estrutura que escolho e, embora goste da idéia da camada adicional de abstração que o ORM fornece, estou começando a perceber o que isso realmente significa. Isso significa que não estou mais trabalhando com meu banco de dados (mysql) e quaisquer recursos específicos do mysql desapareceram pela janela, como se não existissem.

A idéia do ORM é que ele está tentando me ajudar, tornando tudo independente do banco de dados. Isso parece ótimo, mas muitas vezes há uma razão pela qual escolhi um sistema de banco de dados específico. Mas, seguindo a rota independente do banco de dados, o ORM adota o menor denominador comum, o que significa que acabo com o menor conjunto de recursos (os suportados por todos os bancos de dados).

E se eu souber que, a longo prazo, não mudarei o banco de dados subjacente? Por que não acessar os recursos específicos do banco de dados também?

jblue
fonte
2
+1: muito interessante. Geralmente, sou um defensor das ORMs, mas geralmente considero o RDBMS igual (o que recentemente comecei a ver como errado).
Steven Evers
Parece que você só quer confirmação da sua própria opinião; um blog pode ser mais adequado que um site de perguntas e respostas.
Você provavelmente não precisa de nada além do que o ORM fornece. Você só quer armazenar seus dados de objeto em um banco de dados e é isso que o ORM fará. Você não precisa de outros recursos.
CJ7

Respostas:

14

Eu vejo da mesma maneira. Qualquer abstração que não permita que você fique embaixo dela quando necessário é ruim, porque leva a todos os tipos de inversões feias de abstração em seu código.

No trabalho, temos um ORM caseiro que funciona razoavelmente bem, mas nos momentos em que precisamos de algo que seus recursos não fornecem explicitamente, existe um método que pega uma string e a coloca diretamente na consulta que está gerando, permitindo para o uso de SQL bruto quando necessário.

OMI qualquer ORM que não tem esse recurso não vale os bits que é compilado.

Mason Wheeler
fonte
drops it directly into the query it's generatingSoa interessante. Você sabe quanto tempo você levou para escrever este ORM caseiro? Eu gostaria de ver algo assim em um dos ORMs de código aberto disponíveis no mercado.
Jblue 23/09/10
+1. Trabalhar com o aspecto mais importante do meu aplicativo (dados) é a última coisa que quero abstrair e perder a conexão.
Fosco
1
Gosto de poder mergulhar quando necessário, desde que esse mergulho envolva atravessar uma cerca metafórica: "Aqui estejam dragões. Cuidado com o passo".
Frank Shearar
1
@Jblue: Não faço ideia. Foi tudo escrito anos atrás, muito antes de eu ser contratado. Eles criaram um ORM antes que alguém usasse o termo. Geralmente é chamado apenas "o Modelo de Objeto" em nossa base de código.
Mason Wheeler
3
Concordo. Para as coisas básicas e usuais, os ORMs são muito úteis. Mas, às vezes, você precisa se aprofundar um pouco mais e, se o ORM não fornecer essa capacidade, é mais uma fonte de problemas para você.
Nikos Steiakakis
14

o ORM assume o menor denominador comum

Devo discordar da sua declaração. Vou levar nHibernate como um exemplo. Essa estrutura suporta muitos bancos de dados, incluindo os mais populares, independentemente da versão (e dos recursos suportados), assim como a maioria dos ORMs.

Nota rápida: você menciona apenas a abstração do banco de dados. Esse é um dos muitos benefícios, mas eu realmente acho que os recursos orientados a objetos são mais poderosos (por exemplo: herança). E You design your domain model first...

... De volta à abstração. Não é o menor denominador comum. No nHibernate , você tem dialetos. Ele permite que você use o mesmo código para consultar bancos de dados diferentes. Os dialetos cuidam do gerenciamento de recursos para você. A afirmação correta é essa a given dialect will try to use all the power of a given database system.

Como exemplo, considere o SqlServer2005dialeto que, quando introduzido, estava aproveitando os novos recursos de paginação do SQL Server 2005. Usar esse dialeto em vez de SqlServer2000apenas aumentar suas performances.

É claro que existem exceções, mas não encontrei nenhuma em muitos anos trabalhando com o nHibernate, e meus aplicativos são muito centrados em dados.


fonte
+1 por defender o NHibernate. Um pouco de uma curva de aprendizado em comparação com outros ORMs, mas o esforço vale a pena.
richeym 23/09/10
1
Eu gostaria de ouvir de alguns DBAs sobre isso. No meu último emprego, Hibernate era nada além de problemas (o SQL gerou foi absolutamente repugnante.)
Fosco
+1 para este comentário. Está no local. Quando você começa a comparar o poder de um bom ORM como o nHibernate (com armazenamento em cache, carregamento lento, etc), você vê por que essa abstração é boa e por que suas necessidades específicas do banco de dados são menos importantes.
Chris Holmes
1
Fosco, dê ao nHibernate outra chance. Como qualquer outro técnico, você precisa entender o que está acontecendo lá dentro, para usá-lo adequadamente.
+1, ORM é uma interseção máxima do que Java pode fazer com o que um driver JDBC específico pode fazer. Você é livre para escolher a quantidade de investimentos que você quer fazer na camada de persistência de sua aplicação
bobah
5

A ideia é clara, mas nunca fui levado ao ponto de usar uma ferramenta ORM. Não é um problema para mim escrever o SQL (ou manipular qualquer armazenamento usado). Mas, tenho o luxo de trabalhar em um número menor de projetos com vida útil mais longa do produto; portanto, uma vez que a manipulação de SQL e DB codificada manualmente esteja em vigor, ela estará em vigor. Além disso, obviamente, você pode lidar com quaisquer consultas SQL diretas necessárias, sem precisar ajustar seu processo ao modo de pensar da ferramenta ORM.

Então, acho que as perguntas devem ser antes de você pular em uma:

Você está realmente ganhando alguma coisa ao usá-los? Ou seja, você está economizando um esforço suficiente implementando uma ferramenta ORM para valer a pena usá-la e para adicionar uma complicação extra ao seu sistema? (isso é particularmente verdade em aplicativos comerciais, nos quais essa peça extra agora é um vetor extra para possíveis problemas de suporte)

E então, a camada de abstração extra terá um impacto negativo no aplicativo? Será mais lento que o SQL codificado manualmente, etc.

GrandmasterB
fonte
5

O / RM tem sido criticado regularmente. Ted Neward chamou o " Vietnã da Ciência da Computação " alguns anos atrás. O / RM

começa bem, fica mais complicado com o passar do tempo e, em pouco tempo, coloca seus usuários em um compromisso que não possui um ponto de demarcação claro, sem condições claras de vitória e sem uma estratégia clara de saída.

A menos que você escreva seu próprio mapeamento ad-hoc (que é uma boa solução em muitos casos, como outros já disseram), você pode procurar alternativas como o uso de banco de dados não relacional. Alguns dizem que um banco de dados verdadeiramente de objetos é melhor, outras palavras-chave mencionadas nesse contexto são LINQ, Ruby e Tutorial D. Suponho que, ao contrário dos bancos de dados verdadeiramente relacionais, existem realmente bancos de dados de objetos. Mas, na prática, descobri que a modelagem conceitual de dados - ou seja, para descobrir quais objetos do mundo real você deseja armazenar dados e como esses objetos se relacionam - é mais importante do que descobrir como expressar seu modelo conceitual em qualquer linguagem de programação ou banco de dados.

Jakob
fonte
2
Ótima leitura lá. Cheguei a um círculo completo na carreira e re-abracei o modelo relacional com total sucesso.
Jé Queue
2
+1 @Xepoch - Eu tive uma recente sobre face re: ORMs - por que o SQL está sendo deixado de fora no frio? Abstração, com certeza - mas o ORM parece promover a fobia do SQL.
sunwukung
1
@sunwukung, nem sempre eu concordo, mas agora acredito que o SQL deve ser considerado uma camada lógica de primeira classe, não apenas algo que é usado como um protocolo de conexão.
Jé Queue
3

Qual a alternativa?

Esta é uma noção interessante. Abstraindo os recursos do banco de dados subjacente, definitivamente perdemos alguns dos recursos da implementação específica do banco de dados. (Se devemos ou não depender de recursos específicos do banco de dados é outro argumento) Acho que isso pode ser resolvido por ORMs específicos do banco de dados que permitem acessar os recursos específicos, mas isso pode ser apenas mais problemas do que vale a pena e é uma etapa do processo. direção errada.

No final do dia, você deve se perguntar - qual é a alternativa?

Devemos parar de usar ORMs e voltar a escrever todos os acessos ao banco de dados? Certamente, podemos perder o acesso a alguns recursos do banco de dados por meio do ORM, mas você sempre pode acessar aqueles que usam técnicas antigas. No final, os ganhos em produtividade superam completamente as desvantagens.

Jaco Pretorius
fonte
Eu questionaria a necessidade de usar um banco de dados racional. Incomoda-me que as pessoas saltem imediatamente para RDBMSes, mesmo que não sejam a solução certa. Os bancos de dados de objetos, por exemplo, fornecem uma solução muito elegante para muitos problemas. Eles são perfeitos? Não, mas as pessoas raramente se preocupam em avaliá-las. Há uma tendência perturbadora de "Preciso armazenar dados, vou usar SQL!"
Matt Olenik 23/09/10
6
@Matt: RDBMSes são uma tecnologia muito comprovada e comprovada. Há toneladas de pessoas com experiência com eles e um grande número de ferramentas de terceiros. Do ponto de vista corporativo, há muito valor nisso quando você lida com algo extremamente valioso, como seus dados. Em projetos menores, ainda há valor em poder iniciar um projeto (como um serviço da Web LAMP) e ter a maioria do software ali e bem documentada.
David Thornley
3

Um ORM basicamente equivale a " Procedimentos não armazenados ". Lá, eu cunhei um termo.

Tudo o que um ORM faz, você pode replicar com modos de exibição, disparadores e procedimentos armazenados. Eles ajudam a abstrair o SQL bruto e podem manter os bancos de dados normalizados consistentes. Mas isso só funciona bem para casos simples. Se houver muitos dados mach para processar, eles podem se tornar um problema de desempenho. (ORMs no PHP geralmente usam os dados no lado do script, porque as cadeias do construtor SQL não podem abstrair tudo.)

Mas, como sempre, tudo depende do aplicativo e da tarefa em questão.

mario
fonte
2
"Procedimentos não armazenados" - o termo apropriado é "SQL parametrizado". Você está apenas arranhando a superfície do que um ORM maduro pode fazer por você (lotes, carregamento lento etc)
richeym
@richeym: A maioria dos ORMs no PHP não usa instruções preparadas nem espaços reservados parametrizados. É escape e concatenação do SQL todo o caminho. Claro que eles oferecem vantagens de nível superior em relação às tediosas consultas SQL manuais. Sementicamente, no entanto, eles retiram a lógica de processamento do banco de dados, portanto, "procedimentos não armazenados".
mario
3

Uma coisa que machuca ao usar ORMs é que muitos de seus fãs tendem a afirmar que não precisamos mais conhecer a teoria SQL e RDB. Os resultados variam de engraçado a totalmente catastrófico. E isso apesar dos milhões de vezes que os ORM 'fabricam e especialistas afirmam que devemos conhecer bem a teoria SQL e RDB para usar e configurar adequadamente um ORM.

Por que as pessoas usam uma ferramenta que tem seus usos em muitos, mas nem todos os contextos, em uma bala de prata mágica e universalmente aplicável está além de mim.

luis.espinal
fonte
1

No ano passado, trabalhei em um aplicativo interno que mudava com frequência e fiquei muito feliz por termos usado um ORM. O aplicativo era um aplicativo de suporte para uma equipe de gerenciamento de mudanças e, à medida que o projeto maior evoluiu, nosso pequeno aplicativo ganhou novos requisitos para situações que não existiam e que não podiam ser previstas alguns meses antes.

Graças ao ORM ( Propel , em PHP), dividimos parte da lógica do código; portanto, uma função adicionou a parte "é válido para registros" da consulta e outra a parte de segurança ("mostra esses registros apenas se o usuário possui esses recursos "), ... Se a estrutura subjacente for alterada (um campo extra que deve ser levado em consideração para" validade do registro "), teremos que alterar apenas uma função, não vinte cláusulas SQL.

Viemos de uma situação em que todas (bem, a maioria) das cláusulas SQL eram armazenadas em um arquivo XML separado, portanto, "as alterações no banco de dados seriam fáceis de lidar". Acredite, eles não eram. Uma parte foi tão horrível que tive que enviá-la ao The Daily WTF .

Se uma consulta era muito complicada para ser expressa com os Critérios Propel, ou precisávamos de alguns recursos específicos do fornecedor (principalmente pesquisa de texto completo, já que estávamos usando o MySQL), não havia problema com o Propel. Você pode adicionar critérios personalizados ou, quando realmente necessário, usamos SQL bruto ( agora ainda mais fácil de combinar com objetos Propel reais). Você pode adicionar facilmente seus complementos específicos de fornecedor às classes geradas, para ter o melhor dos dois mundos: sem SQL no código do aplicativo, mas com todos os recursos do mecanismo de banco de dados.

Jan Fabry
fonte
1

Mas o ponto é que você começa a se afastar do banco de dados, o que significa que você não precisa pensar como se estivesse no banco de dados.

Eu trabalho em C # agora e uso muito o LINQ, portanto muitos métodos fluentes. Não preciso pensar em como meus objetos são armazenados ou encontrados, ou mesmo salvos no nível do programa e muito pouco no nível da camada de negócios.

Frequentemente, os métodos fornecidos pelos próprios bancos de dados específicos são usados ​​no DB Connector, para que você obtenha essas otimizações sem precisar saber o que são.

Você ainda pode escrever funções no lado do banco de dados. Muitas vezes você pode apenas mapeá-los.

E, acima de tudo, uma separação como essa permite a testabilidade e força você (um pouco) a escrever um código melhor estruturado

mão queimada
fonte
2
Novamente, por que você precisa se programar para longe do banco de dados? Por que não tornar o banco de dados parte integrante do seu desenvolvimento, pois você optou por usá-lo em primeiro lugar. Se você não precisava de um RDBMS, por que colocar um ORM em cima dele?
Jé Queue
1
É uma parte integrante. Um banco de dados se sai muito bem em manter e impor relações e recuperar dados brutos. No entanto, o que você deseja fazer com esses dados provavelmente já foi tratado no wrapper ORM. Além de coisas críticas, por que tirar a lógica da camada de negócios?
Burnt_hand 6/10/10
@burnt_hand - "Mas o ponto é que você começa a se afastar do banco de dados, o que significa que você não precisa pensar como se estivesse no banco de dados." Quais são as vantagens universais? Vejo isso como uma vantagem quando seu aplicativo está simplesmente procurando uma maneira de persistir objetos. Porém, para dados relacionais, OLTP e similares, programar fora do banco de dados é uma maneira de estragar tudo.
Luis.espinal 13/10/10
@ luis.espinal - o que significa estragar sua auto grande momento? sou genuinamente curioso. Você tem um exemplo?
Burnt_hand 14/10
@ burnt_hand - na verdade, tenho vários exemplos reais. O mais recente envolve um modelo de domínio muito grande e, por uma questão de desempenho, o projeto deve carregar todos os mapeamentos de hibernação na inicialização. A fábrica de sessões resultante acaba consumindo até 30% da memória usada ... apenas para as ligações. A base de código está muito comprometida agora com o ORM e é impossível reescrevê-la. Isso agora tem implicações reais, pois o aplicativo está se aproximando dos limites físicos do hardware que deveria executar. Vadio.
Luis.espinal 14/10/10
1

Os ORMs também podem fornecer acesso a recursos específicos do banco de dados, depende de qual ORM você está usando e de quais recursos ele fornece.

Por exemplo, no projeto atual em que estou trabalhando, estamos usando a Java Persistence API e o Hibernate. Mesmo assim, usamos vários recursos específicos do banco de dados, como pesquisar em tabelas com soundex.

Para mim, o principal benefício do uso de um ORM não é necessariamente que ele torna um banco de dados de aplicativos independente (embora isso também seja uma coisa boa), mas que, na maioria das vezes, não preciso pensar em como as coisas são armazenadas e armazenadas. recuperado.

No entanto , em algum momento, você provavelmente precisará pensar sobre isso de qualquer maneira, dependendo dos requisitos para seu aplicativo. O ORM não é mágico.

Vetle
fonte
1

Eu escrevi o meu próprio, o que me ajuda a fazer seleções e inserções mais fáceis.

Evey db coisa específica está disponível. Eu só preciso escrever a consulta com a qual a biblioteca me ajuda (eu posso usar '?' E parâmetros em vez de nomear manualmente um parâmetro e usar .Add)

Acho que a minha metade é meio útil. Eu recebo ajuda no mundo do ORM e faço partes significativas no mundo das consultas.


fonte
1

Escrever código para inserir e selecionar, atualizar em linha ou com procs armazenados e mapeá-los de volta através do DAL é a norma mais longa e apenas benéfica no caso excepcional. Os ORMs disponíveis, os bancos de dados de suporte e os idiomas, a pergunta que você deve fazer por que não está usando o ORM?

Eles são padronizados, universais, especificados ou genéricos. além disso, é mais rápido e fácil de implementar. Eu usei subsônico, linq-to-sql e a estrutura da entidade. Ele permite que o desenvolvedor se concentre na lógica e nas regras de negócios, em vez do mapeamento do banco de dados.

Nickz
fonte
1
Há muitas razões para usar ou NÃO usar um ORM. ORMs não são uma panacéia e muito poucas pessoas sabem como usá-las efetivamente. Além disso, em muitos casos, a lógica de negócios já se reflete (em parte) de maneira muito natural nas relações já existentes em um RDBMS (esse foi o cenário mais comum que encontrei, passado e presente). Um RDBM bem projetado tem uma base matemática forte, bem compreendida, testada e comprovada. Nem tudo deve ser modelado com um RDMB, é claro, mas igualmente, um ORM também não é uma solução universal.
Luis.espinal 13/10/10
1

Meus (simples) dois centavos:

1: Existem ORMS e existem ORMS. Alguns ORMS são baseados no Active Record, outros baseados no Data Mapper - isso por si só é uma consideração relevante, mas requer uma investigação para entender as implicações. Em geral - minha experiência em PHP é que o ORMS suporta o primeiro, poucos suportam o último. Os ORMs baseados no Active Record parecem ter um dos dois efeitos - des normalizam o banco de dados ou invocam uma infinidade de classes para suportar interações com objetos.

2: A vantagem dos ORMs diminui na correlação direta com a complexidade da consulta que você precisa executar. Quando você tem um bom relacionamento simples - por exemplo, Usuários -> Postagens, eles podem funcionar muito bem. É por isso que a maioria dos ORMs / estruturas usa exemplos como este. Quando você precisa executar consultas complexas, no entanto, a quantidade de ORMQL que você precisa gerar é comparável ao tamanho da string de uma consulta SQL regular - mas com menos desempenho devido ao gráfico de objeto em execução que a consulta chama, o que meio que derrota o ponto de abstração. Então, em poucas palavras - os ORM são brilhantes para os primeiros 30-50% das tarefas do banco de dados -, mas terríveis para o final. Eu acho que essa é outra razão pela qual a AR é tão prevalente.

3: Por que esconder do banco de dados? Você usaria uma linguagem do lado do servidor para abstrair o javascript?

Pessoalmente, misturo essas abordagens:

  • use o ORM para o básico, carregando "usuários"
  • use um DAO contendo várias consultas SQL pré-configuradas (por exemplo, selectLike, selectWhere).
  • estenda o DAO onde necessário para adicionar consultas personalizadas mais específicas, mas reutilizáveis
  • Forneça acesso simples ao banco de dados através do DAO - ou seja, $ data = Dao-> query (sua string sql) para executar consultas únicas.

Dito tudo isso, Doutrina 2 será lançada em breve, o que parece realmente interessante.

sunwukung
fonte
0

Você pode usar estruturas do mapeador SQL como myBatis se desejar utilizar os recursos sql.

kolchanov
fonte
Isso não é realmente uma resposta à pergunta de jblue sobre os benefícios de usar tal mapeador
Lukas Eder