NHibernate versus LINQ to SQL

StackOverflow https://stackoverflow.com/questions/26971

Pergunta

Como alguém que não usou nenhuma das tecnologias em projetos do mundo real, pergunto-me se alguém sabe como essas duas se complementam e o quanto suas funcionalidades se sobrepõem.

Foi útil?

Solução

LINQ to SQL força você a usar o padrão tabela por classe.Os benefícios de usar esse padrão são que ele é rápido e fácil de implementar e exige muito pouco esforço para colocar seu domínio em execução com base em uma estrutura de banco de dados existente.Para aplicativos simples, isso é perfeitamente aceitável (e muitas vezes até preferível), mas para aplicativos mais complexos, os desenvolvedores geralmente sugerem o uso de um design orientado por domínio em vez disso (que é o que o NHibernate facilita).

O problema com o padrão tabela por classe é que a estrutura do seu banco de dados tem uma influência direta sobre o design do seu domínio.Por exemplo, digamos que você tenha uma tabela Clientes com as seguintes colunas para armazenar as informações de endereço principal de um cliente:

  • Endereço da Rua
  • Cidade
  • Estado
  • Fecho eclair

Agora, digamos que você também queira adicionar colunas para o endereço de correspondência do cliente, então adicione as seguintes colunas à tabela Clientes:

  • MailingStreetAddress
  • MailingCity
  • Estado de correspondência
  • MailingZip

Usando LINQ to SQL, o objeto Customer em seu domínio agora teria propriedades para cada uma dessas oito colunas.Mas se você estivesse seguindo um padrão de design controlado por domínio, provavelmente teria criado uma classe Address e sua classe Customer teria duas propriedades Address, uma para o endereço de correspondência e outra para o endereço atual.

Esse é um exemplo simples, mas demonstra como o padrão tabela por classe pode levar a um domínio um tanto malcheiroso.No final, depende de você.Novamente, para aplicativos simples que precisam apenas da funcionalidade básica CRUD (criar, ler, atualizar, excluir), o LINQ to SQL é ideal devido à simplicidade.Mas pessoalmente gosto de usar o NHibernate porque facilita um domínio mais limpo.

Editar:@lomaxx - Sim, o exemplo que usei era simplista e poderia ter sido otimizado para funcionar bem com LINQ to SQL.Eu queria mantê-lo o mais básico possível para deixar claro o que quero dizer.A questão permanece, porém, que existem vários cenários em que fazer com que a estrutura do seu banco de dados determine a estrutura do seu domínio seria uma má ideia ou, pelo menos, levaria a um design OO abaixo do ideal.

Outras dicas

Dois pontos que foram perdidos até agora:

Também o novo interface fluente para Nhibernate parece tornar menos penoso configurar o mapeamento do Nhibernate.(Removendo um dos pontos problemáticos do Nhibernate)

Atualizar

Linq to Nhiberate é melhor no Nhiberate v3 que agora está em alfa.Parece que o Nhiberate v3 poderá ser lançado no final deste ano.

O Estrutura de entidade a partir do .net 4 também está começando a parecer uma opção real.

@Kevin:Acho que o problema com o exemplo que você está apresentando é que você está usando um design de banco de dados ruim.Eu teria pensado que você criaria uma tabela de clientes e uma tabela de endereços e normalizaria as tabelas.Se você fizer isso, definitivamente poderá usar o Linq To SQL para o cenário que está sugerindo.Scott Guthrie tem um ótima série de posts sobre como usar Linq To SQL que eu sugiro fortemente que você dê uma olhada.

Eu não acho que você poderia dizer que Linq e NHibernate se complementam, pois isso implicaria que eles poderiam ser usados ​​juntos e, embora isso seja possível, é muito melhor escolher um e segui-lo.

O NHibernate permite mapear as tabelas do seu banco de dados para os objetos do seu domínio de uma forma altamente flexível.Também permite usar HBL para consultar o banco de dados.

Linq to SQL também permite mapear seus objetos de domínio para o banco de dados, no entanto, ele usa a sintaxe de consulta Linq para consultar o banco de dados

A principal diferença aqui é que a sintaxe da consulta Linq é verificado em tempo de compilação pelo compilador para garantir que suas consultas sejam válidas.

Algumas coisas que você deve saber sobre o linq é que ele está disponível apenas no .net 3.x e só é compatível com o VS2008.NHibernate está disponível em 2.0 e 3.x, bem como em VS2005.

Algumas coisas que você deve estar ciente do NHibernate é que ele não gera seus objetos de domínio, nem gera os arquivos de mapeamento.Você precisa fazer isso manualmente.Linq pode
faça isso automaticamente para você.

Fluent NHibernate pode gerar seus arquivos de mapeamento com base em convenções simples.Sem gravação XML e com digitação forte.

Recentemente trabalhei em um projeto onde precisávamos mudar de Linq To SQL para NHibernate por motivos de desempenho.Especialmente a maneira de materializar os objetos do L2S parece mais lenta do que o mesmo do NHibernate e o gerenciamento de mudanças também é bastante lento.E pode ser difícil desativar o gerenciamento de mudanças em cenários específicos onde ele não é necessário.

Se você for usar suas entidades desconectadas do DataContext - em cenários WCF, por exemplo - você poderá ter muitos problemas para conectá-las ao DataContext novamente para atualizar as alterações.Não tive problemas com isso com o NHibernate.

O que sentirei falta no L2S é principalmente a geração de código que mantém as relações atualizadas em ambas as extremidades das entidades.Mas acho que existem algumas ferramentas para o NHibernate fazer isso também...

Você pode esclarecer o que você quer dizer com "LINQ"?

LINQ não é uma tecnologia de acesso a dados, é apenas um recurso de linguagem que suporta consultas como uma construção nativa.Ele pode consultar qualquer modelo de objeto que suporte interfaces específicas (por exemplo,IConsultável).

Muitas pessoas se referem ao LINQ To SQL como LINQ, mas isso não é nada correto.A Microsoft acaba de lançar o LINQ To Entities com .NET 3.5 SP1.Além disso, o NHibernate possui uma interface LINQ, então você pode usar LINQ e NHibernate para obter seus dados.

Por LINQ, presumo que você queira dizer LINQ to SQL porque o LINQ, por si só, não tem nenhum banco de dados "acontecendo" associado a ele.É apenas uma linguagem de consulta que possui um monte de açúcar sintac para fazer com que pareça SQL.

Nos exemplos básicos, NHibernate e LINQ to SQL parecem estar resolvendo o mesmo problema.Depois de passar por isso, você logo perceberá que o NHibernate tem suporte para muitos recursos que permitem criar modelos de domínio verdadeiramente ricos.Há também um projeto LINQ to NHibernate que permite usar o LINQ para consultar o NHibernate da mesma maneira que você usaria o LINQ to SQL.

Primeiro vamos separar duas coisas diferentes:A modelagem de banco de dados se preocupa com os dados, enquanto a modelagem de objetos se preocupa com entidades e relacionamentos.

A vantagem do Linq-to-SQL é gerar rapidamente classes fora do esquema do banco de dados para que possam ser usadas como objetos de registro ativo (consulte definição de padrão de design de registro ativo).

A vantagem do NHibernate é permitir flexibilidade entre a modelagem de objetos e a modelagem de banco de dados.O banco de dados pode ser modelado para melhor refletir seus dados, levando em consideração o desempenho, por exemplo.Embora sua modelagem de objetos reflita melhor os elementos da regra de negócios usando uma abordagem como Domain-Driven-Design.(veja o comentário de Kevin Pang)

Com bancos de dados legados com modelagem e/ou convenções de nomenclatura ruins, o Linq-to-SQL refletirá essas estruturas e nomes indesejados para suas classes.No entanto, o NHibernate pode esconder essa bagunça com mapeadores de dados.

Em projetos greenfield onde os bancos de dados têm boa nomenclatura e baixa complexidade, o Linq-to-SQL pode ser uma boa escolha.

No entanto, você pode usar Fluent NHibernate com mapeamentos automáticos para este mesmo propósito com mapeamento como convenção.Neste caso você não se preocupa com nenhum mapeador de dados com XML ou C# e deixa o NHibernate gerar o esquema do banco de dados a partir de suas entidades com base em uma convenção que você pode personalizar.

Por outro lado, a curva de aprendizado do Linq-to-SQL é menor que a do NHibernate.

Ou você pode usar o projeto Castle ActiveRecords.Estou usando isso há pouco tempo para desenvolver um novo código para um projeto legado.Ele usa NHibernate e funciona no padrão de registro ativo (surpreendente, dado o nome que eu conheço).Eu não tentei, mas presumo que depois de usá-lo, se você sentir necessidade de recorrer diretamente ao suporte do NHibernate, não seria demais fazê-lo para parte ou todo o seu projeto.

Como você escreveu "para uma pessoa que não usou nenhum deles" O LINQ para SQL é fácil de usar para que qualquer um possa usá -lo facilmente, ele também suporta procedimentos, o que ajuda na maioria das vezes.Suponha que você queira obter dados de mais de uma tabela, então escreva um procedimento e arraste esse procedimento para o designer e eles criarão tudo para você, suponha que o nome do seu procedimento seja "Customer_Order_LineItem", que busca o registro de todas essas três tabela e, em seguida, apenas escreva

MyDataContext db = new MyDataContext();
List<CUSTOMER_ORDER_LINEITEMResult> records = db.CUSTOMER_ORDER_LINEITEM(pram1, param2 ...).ToList<CUSTOMER_ORDER_LINEITEMResult>();

você também pode usar seu objeto de registros no loop foreach, o que não é suportado pelo NHibernate

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top