Existem boas razões para não usar um ORM? [fechadas]


107

Durante meu aprendizado, usei o NHibernate para alguns projetos menores, que na maioria das vezes codifiquei e projetei sozinho. Agora, antes de iniciar algum projeto maior, surgiu a discussão sobre como projetar o acesso aos dados e se deve ou não usar uma camada ORM. Como ainda estou em meu aprendizado e ainda me considero um iniciante em programação empresarial, não tentei realmente forçar minha opinião, que é que usar um mapeador relacional de objetos para o banco de dados pode facilitar muito o desenvolvimento. Os outros programadores da equipe de desenvolvimento são muito mais experientes do que eu, então acho que farei o que eles mandarem. :-)

No entanto, não entendo completamente duas das principais razões para não usar o NHibernate ou um projeto semelhante:

  1. Pode-se simplesmente construir seus próprios objetos de acesso a dados com consultas SQL e copiar essas consultas do Microsoft SQL Server Management Studio.
  2. Depurar um ORM pode ser difícil.

Então, é claro que eu poderia simplesmente construir minha camada de acesso a dados com muitos SELECTs etc, mas aqui eu perco a vantagem de junções automáticas, classes de proxy de carregamento lento e um menor esforço de manutenção se uma tabela receber uma nova coluna ou uma coluna receber renomeado. (Atualização numerosos SELECT, INSERTe UPDATEconsultas vs. atualizar a configuração de mapeamento e possivelmente refatoração das classes empresariais e DTOs.)

Além disso, usando o NHibernate, você pode ter problemas imprevistos se não conhecer o framework muito bem. Isso poderia ser, por exemplo, confiar no Table.hbm.xml onde você define o comprimento de uma string para ser validado automaticamente. No entanto, também posso imaginar bugs semelhantes em uma camada de acesso a dados baseada em consulta SqlConnection “simples”.

Finalmente, esses argumentos mencionados acima são realmente um bom motivo para não utilizar um ORM para um aplicativo corporativo baseado em banco de dados não trivial? Existem provavelmente outros argumentos que eles / eu podemos ter perdido?

(Eu provavelmente deveria acrescentar que acho que este é o primeiro grande aplicativo baseado em .NET / C # que exigirá trabalho em equipe. Boas práticas, que são vistas como bastante normais no Stack Overflow, como teste de unidade ou integração contínua, não são -existindo aqui até agora.)

Respostas:


26

Houve uma explosão de crescimento com ORMs nos últimos anos e seus colegas de trabalho mais experientes ainda podem estar pensando na mentalidade de "cada chamada de banco de dados deve ser por meio de um procedimento armazenado".

Por que um ORM tornaria as coisas mais difíceis de depurar? Você obterá o mesmo resultado se vier de um procedimento armazenado ou do ORM.

Acho que o único prejuízo real em que posso pensar com um ORM é que o modelo de segurança é um pouco menos flexível.

EDIT: Acabei de reler sua pergunta e parece que eles estão copiando e colando as consultas em sql embutido. Isso torna o modelo de segurança o mesmo que um ORM, portanto, não haveria absolutamente nenhuma vantagem sobre essa abordagem em relação a um ORM. Se eles estiverem usando consultas não parametrizadas, isso seria, na verdade, um risco de segurança.


1
Mais difícil de depurar: se uma exceção for lançada, você provavelmente precisará conhecer a estrutura em vez de saber as exceções do SqlConnection etc.
hangy

4
A exceção sql não faria parte da exceção ORM?
Giovanni Galbo

1
Sim, a maioria envolve a exceção, então você ainda seria capaz de obter a exceção de origem por meio de .inner
mattlant

Como eu disse, não trouxe esse argumento. :) Claro, a exceção SQL real deve estar em algum lugar no rastreamento da pilha. Como você deve ter lido em minha pergunta, meio que concordo com sua resposta, mas vou esperar para aceitá-la. Talvez outra pessoa venha com boas razões contra ORM.
hangy,

Que tal se sua estrutura de banco de dados for muito diferente de seus objetos de negócios. Isso não transformaria tudo em uma sobrecarga? programar os mapeamentos com xml, ao invés de apenas fornecer as funções necessárias no lado do db com SP's ...?
Uri Abramson

58

A resposta curta é sim, existem razões realmente boas. Na verdade, há casos em que você simplesmente não pode usar um ORM.

Caso em questão, eu trabalho para uma instituição financeira de grande empresa e temos que seguir muitas diretrizes de segurança. Para atender às regras e regulamentos que são impostos a nós, a única maneira de passar nas auditorias é manter o acesso aos dados dentro dos procedimentos armazenados. Agora, alguns podem dizer que isso é simplesmente estúpido, mas honestamente não é. Usar uma ferramenta ORM significa que a ferramenta / desenvolvedor pode inserir, selecionar, atualizar ou excluir o que quiser. Os procedimentos armazenados fornecem muito mais segurança, especialmente em ambientes ao lidar com dados do cliente. Acho que esse é o maior motivo a ser considerado. Segurança.


25
Acho que isso é mais uma limitação das bibliotecas orm atuais que não oferecem suporte a procedimentos armazenados do que uma limitação fundamental ou mapeamento. Existem orm's que podem lidar com visualizações e procs armazenados e há muito a dizer sobre a solução de procs armazenados em orm +.
Mendelt

4
No caso de um bom ORM, você deve conseguir fazer com que ele use SPs de qualquer maneira (é claro, isso atenua muitos dos benefícios ...)
kͩeͣmͮpͥ ͩ

3
O tópico de por que os SPs não fornecem realmente mais segurança do que um ORM é um terreno bem preparado. Aqui está apenas um artigo que aborda bem isso: ayende.com/Blog/archive/2007/11/18/…
Tim Scott

1
Bem, no Sql Server 2005 você não pode simplesmente designar um esquema em um banco de dados apenas para a camada ORM? Ou isso não é suficiente? Se os aplicativos são aplicativos da web, uma coisa é se conectar a um banco de dados. A segurança então foi deixada para a camada de aplicativo.
Mínimo

2
Claro, você pode restringir o que o usuário pode fazer com um ORM. Você apenas define as configurações de segurança do usuário no SQL e dá a ele privilégios para inserir / atualizar / excluir o que você deseja. Seria o mesmo que definir privilégios de segurança para procedimentos armazenados
Doctor Jones,

55

O ponto ideal dos ORMs

ORMs são úteis para automatizar mais de 95% das consultas onde são aplicáveis. Sua força particular é onde você tem um aplicativo com uma arquitetura de modelo de objeto forte e um banco de dados que funciona bem com esse modelo de objeto. Se você estiver fazendo uma nova construção e tiver fortes habilidades de modelagem em sua equipe, provavelmente obterá bons resultados com um ORM.

Você pode muito bem ter um punhado de perguntas que são melhor feitas manualmente. Nesse caso, não tenha medo de escrever alguns procedimentos armazenados para lidar com isso. Mesmo se você pretende portar seu aplicativo em várias plataformas de DBMS, o código dependente do banco de dados será uma minoria. Tendo em mente que você precisará testar seu aplicativo em qualquer plataforma na qual pretende suportá-lo, um pouco de esforço extra de portabilidade para alguns procedimentos armazenados não fará muita diferença para seu TCO. Para uma primeira aproximação, 98% portátil é tão bom quanto 100% portátil e muito melhor do que soluções complicadas ou de baixo desempenho para contornar os limites de um ORM.

Eu vi a abordagem anterior funcionar bem em um projeto J2EE muito grande (100 anos de equipe).

Onde um ORM pode não ser o melhor ajuste

Em outros casos, pode haver abordagens que se adaptem melhor ao aplicativo do que um ORM. Padrões de arquitetura de aplicativos corporativos de Fowler tem uma seção sobre padrões de acesso a dados que faz um bom trabalho ao catalogar várias abordagens para isso. Alguns exemplos que vi de situações em que um ORM pode não ser aplicável são:

  • Em um aplicativo com uma base de código legado substancial de procedimentos armazenados, você pode querer usar uma camada de acesso de dados orientada funcionalmente (não deve ser confundida com linguagens funcionais) para envolver os sprocs incumbentes. Isso reutiliza a camada de acesso a dados existente (e, portanto, testada e depurada) e o design do banco de dados, que geralmente representa um esforço de desenvolvimento e teste bastante substancial e economiza a necessidade de migrar os dados para um novo modelo de banco de dados. Freqüentemente, é uma boa maneira de envolver as camadas Java em torno de bases de código PL / SQL legadas ou redirecionar os aplicativos de cliente avançado VB, Powerbuilder ou Delphi com interfaces da web.

  • Uma variação é quando você herda um modelo de dados que não é necessariamente adequado para mapeamento OR. Se (por exemplo) você está escrevendo uma interface que preenche ou extrai dados de uma interface externa, talvez seja melhor trabalhar diretamente com o banco de dados.

  • Aplicativos financeiros ou outros tipos de sistemas em que a integridade de dados entre sistemas é importante, especialmente se você estiver usando transações distribuídas complexas com confirmação de duas fases. Você pode precisar microgerenciar suas transações melhor do que um ORM é capaz de suportar.

  • Aplicativos de alto desempenho onde você deseja realmente ajustar o acesso ao banco de dados. Nesse caso, pode ser preferível trabalhar em um nível inferior.

  • Situações em que você está usando um mecanismo de acesso a dados incumbente como ADO.Net que é 'bom o suficiente' e funciona bem com a plataforma é um benefício maior do que o ORM traz.

  • Às vezes, os dados são apenas dados - pode ser o caso (por exemplo) de que seu aplicativo esteja trabalhando com 'transações' em vez de 'objetos' e que esta seja uma visão sensata do domínio. Um exemplo disso pode ser um pacote financeiro onde você tem transações com campos de análise configuráveis. Embora o próprio aplicativo possa ser construído em uma plataforma OO, ele não está vinculado a um único modelo de domínio de negócios e pode não estar ciente de muito mais do que códigos GL, contas, tipos de documentos e meia dúzia de campos de análise. Nesse caso, o aplicativo não está ciente de um modelo de domínio de negócios como tal e um modelo de objeto (além da própria estrutura do razão) não é relevante para o aplicativo.


"ou outros tipos de sistemas onde a integridade dos dados é importante" ... Sites sociais à parte, se a integridade dos seus dados não é importante, por que se preocupar em construir um sistema?
ObiWanKenobi

3
O ponto se refere especificamente a transações distribuídas em que vários sistemas devem garantir uma confirmação ou reversão de forma síncrona ou fora de uma fila de mensagens. Nem todos esses sistemas serão desenvolvidos para você e, portanto, não necessariamente oferecerão suporte a um ORM. Você pode ter que gerenciar explicitamente as transações, o que pode exigir que você use um takelit de nível inferior do que um ORM.
ConcernedOfTunbridgeWells

1
Eu sei que já se passou mais de um ano, mas +1 para você por mencionar o fato de que às vezes os dados são apenas isso, dados.
luis.espinal

37

Em primeiro lugar - usar um ORM não tornará seu código mais fácil de testar, nem necessariamente fornecerá quaisquer vantagens em um cenário de Integração Contínua.

Na minha experiência, embora o uso de um ORM possa aumentar a velocidade de desenvolvimento, os maiores problemas que você precisa resolver são:

  1. Testando seu código
  2. Manter seu código

As soluções para isso são:

  1. Torne seu código testável (usando princípios SOLID )
  2. Escreva testes automatizados para o máximo de código possível
  3. Execute os testes automatizados tão frequentemente quanto possível

Voltando à sua pergunta, as duas objeções que você listou parecem mais ignorância do que qualquer outra coisa.

Não ser capaz de escrever consultas SELECT manualmente (o que, presumo, é o motivo pelo qual copiar e colar é necessário) parece indicar que há uma necessidade urgente de algum treinamento em SQL.

Existem dois motivos pelos quais eu não usaria um ORM:

  1. É estritamente proibido pela política da empresa (nesse caso, eu iria trabalhar em outro lugar)
  2. O projeto é extremamente dados soluções intensivas e usando fornecedor específicas (como BulkInsert) faz mais sentido.

As rejeições usuais sobre ORMs (NHibernate em particular) são:

  1. Rapidez

    Não há razão para que usar um ORM seja mais lento do que o acesso a dados codificado manualmente. Na verdade, devido ao armazenamento em cache e às otimizações incorporadas, ele pode ser mais rápido. Um bom ORM produzirá um conjunto repetível de consultas para as quais você pode otimizar seu esquema. Um bom ORM também permitirá a recuperação eficiente de dados associados usando várias estratégias de busca.

  2. Complexidade

    Com relação à complexidade, usar um ORM significa menos código, o que geralmente significa menos complexidade. Muitas pessoas que usam acesso a dados escritos à mão (ou gerado por código) acabam escrevendo sua própria estrutura em bibliotecas de acesso a dados de "baixo nível" (como escrever métodos auxiliares para ADO.Net). Isso equivale a mais complexidade e, pior ainda, raramente são bem documentados ou bem testados.
    Se você está olhando especificamente para NHibernate, ferramentas como Fluent NHibernate e Linq To NHibernate também suavizam a curva de aprendizado.

O que me incomoda em todo o debate sobre ORM é que as mesmas pessoas que afirmam que usar um ORM será muito difícil / lento / qualquer coisa são as mesmas pessoas que estão mais do que felizes usando Linq To Sql ou Conjuntos de dados digitados. Embora o Linq To Sql seja um grande passo na direção certa, ainda está anos-luz atrás de onde estão alguns dos ORMs de código aberto. No entanto, os frameworks para ambos os conjuntos de dados digitados e para Linq To Sql ainda são extremamente complexos, e usá-los para ir muito longe de (Tabela = Classe) + (CRUD básico) é estupidamente difícil.

Meu conselho é que se, no final do dia, você não puder obter um ORM, certifique-se de que seu acesso aos dados seja separado do resto do código e que você siga o conselho do Gang Of Four de codificação para uma interface. Além disso, obtenha uma estrutura de injeção de dependência para fazer a fiação.

(Que tal um discurso retórico?)


33

Há uma grande variedade de problemas comuns para os quais ferramentas ORM como o Hibernate são enviadas por Deus, e alguns em que é um obstáculo. Não sei o suficiente sobre o seu projeto para saber qual é.

Um dos pontos fortes do Hibernate é que você pode dizer coisas apenas 3 vezes: cada propriedade é mencionada na classe, o arquivo .hbm.xml e o banco de dados. Com as consultas SQL, suas propriedades estão na classe, no banco de dados, nas instruções de seleção, nas instruções de inserção, nas instruções de atualização, nas instruções de exclusão e em todo o código de empacotamento e descompactação que suporta suas consultas SQL! Isso pode ficar bagunçado rápido. Por outro lado, você sabe como funciona. Você pode depurá-lo. Está tudo bem em sua própria camada de persistência, não enterrado nas entranhas de uma ferramenta de terceiros.

O Hibernate pode ser um garoto-propaganda da Lei das Abstrações Furadas de Spolsky. Saia um pouco do caminho comum e você precisa conhecer o funcionamento interno profundo da ferramenta. Pode ser muito chato quando você sabe que poderia ter corrigido o SQL em minutos, mas em vez disso, você está gastando horas tentando persuadir sua maldita ferramenta a gerar SQL razoável. A depuração às vezes é um pesadelo, mas é difícil convencer as pessoas que não estiveram lá.

EDIT: Você pode querer olhar para iBatis.NET se eles não vão ser revirados sobre NHibernate e eles querem controle sobre suas consultas SQL.

EDIT 2: Aqui está a grande bandeira vermelha, no entanto: "Boas práticas, que são vistas como bastante normais no Stack Overflow, como teste de unidade ou integração contínua, não existem aqui até agora." Então, esses desenvolvedores "experientes", o que eles têm experiência no desenvolvimento? Sua segurança no trabalho? Parece que você pode estar entre pessoas que não estão particularmente interessadas na área, então não deixe que elas matem o seu interesse. Você precisa ser o equilíbrio. Lute.


3
A repetição não é mais verdadeira. Se você usar anotações JPA, só precisa especificar as coisas uma vez. O Hibernate irá até mesmo construir suas instruções de criação de banco de dados para você, embora isso seja mais útil para determinar se seu mapeamento estava correto.
jonathan-stafford,

Discussão bem equilibrada das questões. Minha experiência com o framework Entity se encaixa exatamente na sua descrição de "passar horas tentando bajular sua maldita ferramenta" e "é difícil convencer as pessoas que não estiveram lá". Aparentemente, foi mais rápido de escrever, mas é uma grande perda de tempo para ter um desempenho muito bom.

2
8 anos se passaram, mas ainda é verdade: "Pode ser muito chato quando você sabe que poderia ter corrigido o SQL em minutos, mas em vez disso, você está gastando horas tentando persuadir sua maldita ferramenta a gerar um SQL razoável."
Ruslan Stelmachenko

13

Trabalhei em um projeto em que não usar um ORM foi muito bem-sucedido. Foi um projeto que

  1. Tinha que ser horizontalmente escalável desde o início
  2. Teve que ser desenvolvido rapidamente
  3. Tinha um modelo de domínio relativamente simples

O tempo que levaria para fazer o NHibernate funcionar em uma estrutura particionada horizontalmente teria sido muito mais longo do que o tempo que levaria para desenvolver um mapeador de dados super simples que estava ciente do nosso esquema de particionamento ...

Então, em 90% dos projetos em que trabalhei, um ORM foi uma ajuda inestimável. Mas existem algumas circunstâncias muito específicas em que posso ver não usar um ORM como sendo o melhor.


Você deu alguns pontos positivos contra o uso de um ORM em alguns casos específicos. Porém, este projeto pertence àqueles 90% onde o ORM possivelmente poderia ajudar a reduzir custos de desenvolvimento e manutenção.
hangy,

Concordo totalmente - desculpe por não responder sua pergunta diretamente! Eu acredito que os motivos específicos que você mencionou são bastante inválidos :)
Mike


11

Deixe-me primeiro dizer que os ORMs podem tornar sua vida de desenvolvimento mais fácil se integrados corretamente, mas há um punhado de problemas em que o ORM pode realmente impedir que você atinja seus requisitos e objetivos declarados.

Descobri que, ao projetar sistemas que têm requisitos de desempenho pesados, geralmente sou desafiado a encontrar maneiras de tornar o sistema mais eficiente. Muitas vezes, acabo com uma solução que tem um perfil de desempenho de gravação pesado (o que significa que estamos gravando muito mais dados do que lendo dados). Nesses casos, quero aproveitar as facilidades que a plataforma de banco de dados me oferece para atingir nossos objetivos de desempenho (é OLTP, não OLAP). Então, se estou usando o SQL Server e sei que tenho muitos dados para escrever, por que não usaria uma inserção em massa ... bem, como você já deve ter descoberto, a maioria dos ORMS (não sei se mesmo um único, não tem a capacidade de tirar vantagem das vantagens específicas da plataforma, como inserto em massa.

Você deve saber que pode combinar as técnicas ORM e não ORM. Acabei de descobrir que existem alguns casos extremos em que os ORMs não podem atender aos seus requisitos e você tem que contorná-los para esses casos.


9

Quando você precisa atualizar 50000000 registros. Defina uma bandeira ou algo assim.

Tente fazer isso usando um ORM sem chamar um procedimento armazenado ou comandos SQL nativos.

Atualização 1: tente também recuperar um registro com apenas alguns de seus campos. (Quando você tem uma mesa muito "larga"). Ou um resultado escalar. ORMs são péssimos nisso também.

ATUALIZAÇÃO 2 : Parece que o EF 5.0 beta promete atualizações em lote, mas esta é uma notícia muito quente (janeiro de 2012)



9

Para um aplicativo corporativo não trivial baseado em banco de dados, realmente não há justificativa para não usar um ORM.

Recursos à parte:

  • Ao não usar um ORM, você está resolvendo um problema que já foi resolvido repetidamente por grandes comunidades ou empresas com recursos significativos.
  • Ao usar um ORM, a peça central de sua camada de acesso a dados se beneficia dos esforços de depuração dessa comunidade ou empresa.

Para colocar alguma perspectiva no argumento, considere as vantagens de usar ADO.NET em vez de escrever o código para analisar o fluxo de dados tabulares por conta própria.

Tenho visto que a ignorância de como usar um ORM justifica o desdém de um desenvolvedor por ORMs. Por exemplo: carregamento rápido (algo que percebi que você não mencionou). Imagine que você deseja recuperar um cliente e todos os seus pedidos e, para aqueles, todos os itens de detalhes do pedido. Se você depende apenas do carregamento lento, abandonará sua experiência de ORM com a opinião: "ORMs são lentos." Se você aprender a usar o carregamento antecipado, fará em 2 minutos com 5 linhas de código, o que seus colegas levarão meio dia para implementar: uma consulta ao banco de dados e vinculando os resultados a uma hierarquia de objetos. Outro exemplo seria a dificuldade de escrever manualmente consultas SQL para implementar a paginação.

A possível exceção ao uso de um ORM seria se esse aplicativo fosse uma estrutura ORM projetada para aplicar abstrações lógicas de negócios especializadas e projetada para ser reutilizada em vários projetos. Mesmo se esse fosse o caso, no entanto, você teria uma adoção mais rápida aprimorando um ORM existente com essas abstrações.

Não deixe que a experiência dos membros da equipe sênior o arraste na direção oposta da evolução da ciência da computação. Estou me desenvolvendo profissionalmente há 23 anos, e uma das constantes é o desprezo pelo novo pela velha escola. Os ORMs estão para o SQL como a linguagem C estava para a montagem, e você pode apostar que os equivalentes para C ++ e C # estão a caminho. Uma linha do código da nova escola equivale a 20 linhas da velha escola.


8

Eu acho que talvez quando você trabalha em sistemas maiores, você pode usar uma ferramenta geradora de código como CodeSmith em vez de um ORM ... Recentemente encontrei isto: Cooperator Framework que gera SQL Server Stored Procedures e também gera suas entidades de negócios, mapeadores, gateways, lazyload e todas essas coisas em C # ... olha só ... foi escrito por uma equipe aqui na Argentina ...

Acho que está no meio entre codificar toda a camada de acesso a dados e usar um ORM ...


6

Pessoalmente, (até recentemente) me oponho a usar um ORM e costumava escrever uma camada de acesso a dados encapsulando todos os comandos SQL. A principal objeção aos ORMs era que eu não confiava na implementação do ORM para escrever exatamente o SQL correto. E, a julgar pelos ORMs que costumava ver (principalmente bibliotecas PHP), acho que estava totalmente certo.

Agora, a maior parte do meu desenvolvimento web está usando Django, e eu achei o ORM incluído realmente conveniente, e como o modelo de dados é expresso primeiro em seus termos e somente depois em SQL, ele funciona perfeitamente para minhas necessidades. Tenho certeza de que não seria muito difícil superá-lo e precisar suplementar com SQL escrito à mão; mas para CRUD o acesso é mais que suficiente.

Não sei sobre o NHibernate; mas acho que também é "bom o suficiente" para a maior parte do que você precisa. Mas se outros programadores não confiarem nele; será o principal suspeito em todos os bugs relacionados a dados, tornando a verificação mais tediosa.

Você pode tentar introduzi-lo gradualmente em seu local de trabalho, focando primeiro em pequenos aplicativos "óbvios", como o simples acesso a dados. Depois de um tempo, ele pode ser usado em protótipos e não pode ser substituído ...


5

Se for um banco de dados OLAP (por exemplo, dados estáticos, somente leitura usados ​​para relatórios / análises, etc.), a implementação de uma estrutura ORM não é apropriada. Em vez disso, seria preferível usar a funcionalidade de acesso a dados nativos do banco de dados, como procedimentos armazenados. ORMs são mais adequados para sistemas transacionais (OLTP).


Você tem certeza sobre isso? OLTPs são tão inadequados com ORMs quanto OLAPs (quero dizer, dependendo da complexidade). Existe uma ampla gama de aplicações entre esses dois extremos para os quais um ORM faz um bom trabalho. Mas para OLAPs e OLTPs, eles podem se tornar um obstáculo.
luis.espinal

4

Acho que há muitos bons motivos para não usar um ORM. Em primeiro lugar, sou um desenvolvedor .NET e gosto de seguir o que o maravilhoso framework .NET já me forneceu. Ele faz tudo que eu possivelmente preciso. Ao fazer isso, você mantém uma abordagem mais padrão e, portanto, há uma chance muito melhor de qualquer outro desenvolvedor trabalhando no mesmo projeto no futuro ser capaz de pegar o que está lá e executar com ele. Os recursos de acesso a dados já fornecidos pela Microsoft são bastante amplos, não há razão para descartá-los.

Tenho sido um desenvolvedor profissional por 10 anos, liderando vários projetos de milhões de dólares e muito bem-sucedidos, e nunca escrevi um aplicativo que precisasse ser capaz de mudar para qualquer banco de dados. Por que você quer que um cliente faça isso? Planeje com cuidado, escolha o banco de dados certo para o que você precisa e continue com ele. Pessoalmente, o SQL Server tem sido capaz de fazer tudo que eu sempre precisei fazer. É fácil e funciona muito bem. Existe até uma versão gratuita que suporta até 10 GB de dados. Ah, e funciona muito bem com o .NET.

Recentemente, tive que começar a trabalhar em vários projetos que usam um ORM como camada de dados. Acho que é ruim, e algo extra que tive que aprender a usar sem motivo algum. Na circunstância insanamente rara em que o cliente realmente precisou mudar os bancos de dados, eu poderia facilmente ter retrabalhado todo o datalayer em menos tempo do que gastei brincando com os provedores de ORM.

Honestamente, acho que há um uso real para um ORM: se você estiver construindo um aplicativo como o SAP, que realmente precisa ser executado em vários bancos de dados. Caso contrário, como um provedor de soluções, digo aos meus clientes que este aplicativo foi projetado para ser executado neste banco de dados e é assim que funciona. Mais uma vez, após 10 anos e inúmeras aplicações, isso nunca foi um problema.

Caso contrário, acho que ORMs são para desenvolvedores que não entendem menos é mais, e acho que quanto mais ferramentas interessantes de terceiros eles usarem em seus aplicativos, melhor será seu aplicativo. Vou deixar coisas assim para os super geeks obstinados enquanto eu crio muito mais softwares excelentes que qualquer desenvolvedor pode pegar e imediatamente ser produtivo.


2
Eu realmente não entendo por que essa resposta foi rejeitada. Manter as coisas simples usando tudo o que seu ambiente tem a oferecer é uma ótima prática. Como um guru experiente de código limpo, acho que os orm são difíceis de ler e, portanto, difíceis de manter. Você não sabe quais consultas são executadas exatamente quando tem relacionamentos complexos em seu aplicativo (o que eventualmente acontecerá). Está se tornando impossível depurar tal bagunça a longo prazo. Eu digo, mantenha as coisas simples, não use ORM.
David

Isso é engraçado. Sou desenvolvedor há 24 anos e nunca estive envolvido em um projeto em que fosse possível dar suporte a apenas um fornecedor de RDBMS. Cada projeto EXIGIU que suportássemos vários fornecedores de RDBMS, porque precisávamos ser flexíveis o suficiente para trabalhar com clientes que REQUEREM Oracle e com outros clientes que REQUEREM SQL Server. Se você estiver construindo um aplicativo de chaminé no vácuo, então sim, você pode simplesmente ditar o RDBMS. Mas nunca me envolvi em um projeto em que isso fosse aceitável.
deltamind106

Tive muitos aplicativos onde posso ditar o RDBMS principalmente por causa de um bom número de aplicativos internos e voltados para o cliente que viram "nossos" dados. Também sou desenvolvedor há 24 anos.
jeffkenn

3

O desempenho em tempo de execução é a única desvantagem real em que posso pensar, mas acho que é mais do que uma troca justa pelo tempo que o ORM economiza no desenvolvimento / teste / etc. E na maioria dos casos, você deve ser capaz de localizar gargalos de dados e alterar suas estruturas de objetos para serem mais eficientes.

Não usei o Hibernate antes, mas uma coisa que percebi com algumas soluções ORM "prontas para o uso" é a falta de flexibilidade. Tenho certeza de que isso depende de como você vai e do que precisa fazer com isso.


Lembro-me de algumas pessoas dizendo que as consultas otimizadas e não carregar dados desnecessários em algumas situações (ou seja, carregamento lento de joins) pode realmente acelerar as coisas. Implementar isso manualmente em um DAL personalizado pode ser mais trabalhoso e valer menos tempo.
hangy,

3

Existem dois aspectos dos ORMs que são preocupantes. Primeiro, eles são códigos escritos por outra pessoa, às vezes de código-fonte fechado, às vezes de código-fonte aberto, mas de escopo enorme. Em segundo lugar, eles copiam os dados.

O primeiro problema causa dois problemas. Você está contando com código de estranhos. Todos nós fazemos isso, mas a escolha de fazê-lo não deve ser tomada de ânimo leve. E se não fizer o que você precisa? Quando você vai descobrir isso? Você mora dentro da caixa que seu ORM desenha para você.

O segundo problema é o commit de duas fases. O banco de dados relacional está sendo copiado para um modelo de objeto. Você altera o modelo de objeto e ele deve atualizar o banco de dados. Este é um commit de duas fases e não a coisa mais fácil de depurar.


2
Umm ... se você estiver usando, digamos .NET, você está contando com o código deles (que você não pode modificar). Eu não vejo como isso é mais "ok" do que confiar no código do NHibernate, por exemplo. Ser paranóico com bibliotecas que você não escreveu é relativamente ridículo. Parece que você sofre de NIH
Jason Bunting,

Compiladores e VMs são uma parte relativamente estável do CS e não são tão difíceis de resolver com testes. um projeto ORM tem várias maneiras de ser 'ligeiramente errado' ou de documentação incompleta. tudo isso torna mais difícil confiar do que algo tão básico como o compilador.
Javier

1
É um aviso ... não uma declaração de não uso. E esse é apenas um aviso entre três questões.
dacracot

1
@dacracot: Você está contando com muitos códigos estrangeiros o tempo todo ... começando pelo seu sistema operacional, então não acho que seu ponto seja válido. O segundo ponto pode ser mitigado usando bloqueio otimista, além disso, não tem muito a ver com o commit de duas fases.
Adam Byrtek

1
dacracot é certeiro ao falar de alguns dos ORMs menos maduros. Tenho certeza de que existem algumas bolas de rock, mas a maioria será imperfeita e pode ser um problema em alguns ambientes (não na maioria). Em relação ao two-phase commit ... existem maneiras de modelar a própria transação do banco de dados no código, mas por que adicionar uma camada de indireção que não fornece nenhuma abstração?
Tom


3

A experiência que tive com o Hibernate é que sua semântica é sutil e, quando há problemas, é um pouco difícil entender o que está errado nos bastidores. Ouvi de um amigo que muitas vezes alguém começa com Critérios, então precisa de um pouco mais de flexibilidade e precisa de HQL, e depois percebe que, afinal de contas, SQL bruto é necessário (por exemplo, o Hibernate não tem união AFAIK).

Também com ORM, as pessoas facilmente tendem a usar em demasia os mapeamentos / modelos existentes, o que leva a que haja um objeto com muitos atributos que não são iniciados. Portanto, após a consulta, a transação interna do Hibernate faz a busca de dados adicionais, o que leva a uma possível desaceleração. Também, infelizmente, o objeto de modelo de hibernação às vezes vaza para a camada de arquitetura de exibição e, então, vemos LazyInitializationExceptions.

Para usar ORM, deve-se realmente entendê-lo. Infelizmente, fica fácil ter a impressão de que é fácil, enquanto não é.


O Hibernate não suporta UNION? Essa é uma parte bastante fundamental da teoria dos conjuntos! Suponho que apenas indica uma maneira diferente de pensar sobre o problema.
Tom de

3

Para não ser uma resposta per se, quero reformular uma citação que ouvi recentemente. "Um bom ORM é como um Yeti, todo mundo fala sobre um, mas ninguém o vê."

Sempre que coloco minhas mãos em um ORM, geralmente me vejo lutando com os problemas / limitações desse ORM. No final, sim, faz o que eu quero e estava escrito em algum lugar naquela documentação nojenta, mas me vejo perdendo mais uma hora que nunca vou conseguir. Qualquer pessoa que usou nhibernate, então nhibernate fluente em postgresql entenderia o que eu tenho passado. O sentimento constante de "este código não está sob meu controle" é realmente uma merda.

Não aponto o dedo ou digo que é ruim, mas comecei a pensar no que estou dando apenas para automatizar o CRUD em uma única expressão. Hoje em dia acho que devo usar menos ORM's, talvez criar ou encontrar uma solução que permita operações de db no mínimo. Mas sou só eu. Acredito que algumas coisas estão erradas nesta área de ORM, mas não sou habilidoso o suficiente para expressar o que não é.


Muitos anos (e ORMs) depois, decidi usar Postgresql / EntityFramework com migrações do Code First. Ele me permite habilitar a persistência de dados por meio de classes que escrevi e, finalmente, posso sincronizar / versão minhas alterações de banco de dados integradas ao meu ambiente de produção. É quase uma camada transparente de acesso aos dados e economiza muito tempo durante o desenvolvimento, mas enquanto isso, posso me aprofundar e escrever consultas avançadas quando quiser. Claro, é uma solução dotnet, mas finalmente estou em paz com o acesso db.
dia

2

Acho que usar um ORM ainda é uma boa ideia. Especialmente considerando a situação que você dá. Pelo seu post, parece que você é o mais experiente no que diz respeito às estratégias de acesso ao banco de dados, e eu mencionaria o uso de um ORM.

Não há nenhum argumento para o nº 1, já que copiar e colar consultas e a codificação em texto não oferece flexibilidade e, para o nº 2, a maioria dos orms envolverá a exceção original, permitirá rastrear as consultas geradas, etc., portanto, depurar também não é uma ciência espacial.

Quanto à validação, o uso de um ORM geralmente também permite um desenvolvimento muito mais fácil de estratégias de validação, além de qualquer validação embutida.

Escrever sua própria estrutura pode ser trabalhoso e muitas vezes algumas coisas passam despercebidas.

EDIT: Eu queria fazer mais um ponto. Se a sua empresa adota uma estratégia ORM, isso aumenta ainda mais o seu valor, pois você desenvolverá diretrizes e práticas de uso e implementação e todos irão aprimorar ainda mais o conhecimento da estrutura escolhida, mitigando uma das questões que você levantou. Além disso, você aprenderá o que funciona e o que não funciona quando as situações surgirem e, no final, economizará muito tempo e esforço.


1

Todo ORM, mesmo um "bom", vem sobrecarregado com um certo número de suposições relacionadas à mecânica subjacente que o software usa para passar dados de um lado para outro entre sua camada de aplicativo e seu armazenamento de dados.

Descobri que, para aplicativos moderadamente sofisticados, trabalhar em torno dessas suposições geralmente leva mais tempo do que simplesmente escrever uma solução mais direta, como: consultar os dados e instanciar manualmente novas entidades.

Em particular, é provável que você tenha problemas assim que usar chaves de várias colunas ou outros relacionamentos moderadamente complexos que estão fora do escopo dos exemplos úteis que seu ORM forneceu quando você baixou o código.

Admito que, para certos tipos de aplicativos, particularmente aqueles que têm um grande número de tabelas de banco de dados, ou tabelas de banco de dados geradas dinamicamente, o processo de mágica automática de um ORM pode ser útil.

Caso contrário, para o inferno com os ORMs. Eu agora os considero basicamente uma moda passageira.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.