Geradores de código vs.ORM vs.Procedimentos armazenados

Question

Em quais domínios cada uma dessas arquiteturas de software brilha ou falha?

Quais requisitos principais levariam você a escolher um em vez de outro?

Suponha que você tenha desenvolvedores disponíveis que possam fazer um bom código orientado a objetos, bem como um bom desenvolvimento de banco de dados.

Além disso, evite guerras santas :) todas as três tecnologias têm prós e contras, estou interessado em saber onde é mais apropriado usar qual delas.

Answer 1

Cada uma dessas ferramentas fornece diferentes camadas de abstração, juntamente com diferentes pontos para substituir o comportamento.Estas são escolhas de arquitetura, e todas as escolhas de arquitetura dependem de compensações entre tecnologia, controle e organização, tanto do próprio aplicativo quanto do ambiente onde ele será implantado.

• Se você estiver lidando com uma cultura onde os DBAs 'governam o poleiro', então uma arquitetura baseada em procedimentos armazenados será mais fácil de implantar.Por outro lado, pode ser muito difícil gerenciar e versionar procedimentos armazenados.

• Os geradores de código brilham quando você usa linguagens de tipo estaticamente, porque você pode detectar erros em tempo de compilação em vez de em tempo de execução.

• ORMs são ideais para ferramentas de integração, onde você pode precisar lidar com diferentes RDBMSes e esquemas de instalação para instalação.Altere um mapa e seu aplicativo deixará de funcionar com PeopleSoft no Oracle e passará a trabalhar com o Microsoft Dynamics no SQL Server.

Já vi aplicativos em que o código gerado é usado para fazer interface com procedimentos armazenados, porque os procedimentos armazenados podem ser ajustados para contornar as limitações do gerador de código.

Em última análise, a única resposta correta dependerá do problema que você está tentando resolver e do ambiente onde a solução precisa ser executada.Qualquer outra coisa é discutir a pronúncia correta de 'batata'.

Answer 2

Vou adicionar meus dois centavos:

Procedimentos armazenados

• Pode ser facilmente otimizado
• Regras de negócios fundamentais abstratas, melhorando a integridade dos dados
• Forneça um bom modelo de segurança (não há necessidade de conceder permissões de leitura ou gravação a um usuário de banco de dados frontal)
• Brilhe quando você tem muitos aplicativos acessando os mesmos dados

ORMs

• Permite que você se concentre apenas no domínio e tenha uma abordagem de desenvolvimento orientada a objetos mais "pura"
• Brilhe quando seu aplicativo deve ser compatível com cross db
• Brilhe quando seu aplicativo é orientado principalmente por comportamento em vez de dados

Geradores de código

• Fornece benefícios semelhantes aos ORMs, com custos de manutenção mais elevados, mas com melhor personalização.
• Geralmente são superiores aos ORMs porque os ORMs tendem a trocar erros em tempo de compilação por erros em tempo de execução, o que geralmente deve ser evitado

Answer 3

Concordo que tudo tem prós e contras e depende muito da sua arquitetura.Dito isto, tento usar ORM onde faz sentido.Muitas funcionalidades já estão lá e geralmente ajudam a evitar a injeção de SQL (além de ajudar a evitar a reinvenção da roda).

Consulte essas outras duas postagens sobre o tópico (SQL dinâmico vs procedimentos armazenados vs orm) para obter mais informações

SQL dinâmico vs.procedimentos armazenados
Qual é melhor:Consultas ad hoc ou procedimentos armazenados?

ORM vs.procedimentos armazenados
Por que o SQL parametrizado gerado pelo NHibernate é tão rápido quanto um procedimento armazenado?

Answer 4

ORMs e geradores de código estão de um lado do campo e os procedimentos armazenados estão do outro.Normalmente, é mais fácil usar ORMs e geradores de código em projetos greenfield, porque você pode personalizar seu esquema de banco de dados para corresponder ao modelo de domínio criado.É muito mais difícil usá-los com projetos legados, porque uma vez que o software é escrito com uma mentalidade de “primeiro os dados”, é difícil envolvê-lo com um modelo de domínio.

Dito isto, todas as três abordagens têm valor.Os procedimentos armazenados podem ser mais fáceis de otimizar, mas pode ser tentador colocar neles uma lógica de negócios que pode ser repetida no próprio aplicativo.Os ORMs funcionam bem se o seu esquema corresponder ao conceito do ORM, mas pode ser difícil de personalizar caso contrário.Os geradores de código podem ser um bom meio-termo, porque fornecem alguns dos benefícios de um ORM, mas permitem a personalização do código gerado - no entanto, se você adquirir o hábito de alterar o código gerado, terá dois problemas, porque você terá que alterá-lo cada vez que você o gerar novamente.

Não existe uma resposta verdadeira, mas tenho mais tendência para o lado ORM porque acredito que faz mais sentido pensar com uma mentalidade que prioriza o objeto.

Answer 5

Procedimentos armazenados

• Prós: Encapsula o código de acesso a dados e é independente da aplicação
• Contras: Pode ser específico do RDBMS e aumentar o tempo de desenvolvimento

ORM

Pelo menos alguns ORMs permitem mapeamento para procedimentos armazenados

• Prós: Abstrai o código de acesso a dados e permite que objetos de entidade sejam escritos de maneira específica do domínio
• Contras: Possível sobrecarga de desempenho e capacidade de mapeamento limitada

Geração de código

• Prós: Pode ser usado para gerar código baseado em procedimento armazenado ou um ORM ou uma combinação de ambos
• Contras: A camada geradora de código pode precisar ser mantida além da compreensão do código gerado

Answer 6

Você esqueceu uma opção significativa que merece uma categoria própria:uma estrutura híbrida de mapeamento de dados, como iBatis.

Fiquei satisfeito com o iBatis porque ele permite que seu código OO permaneça de natureza OO e seu banco de dados permaneça de natureza relacional, e resolve a incompatibilidade de impedância adicionando uma terceira abstração (a camada de mapeamento entre os objetos e as relações) que é responsável por mapeando os dois, em vez de tentar forçar o encaixe de um paradigma no outro.