Devo começar a usar o LINQ To SQL?

Question

Atualmente estou usando NetTiers para gerar minha camada de acesso a dados e camada de serviço.Uso NetTiers há mais de 2 anos e descobri que é muito útil.Em algum momento preciso dar uma olhada no LINQ, então minhas perguntas são ...

1. Alguém mais passou do NetTiers para o LINQ To SQL?
2. Essa mudança foi uma coisa boa ou ruim?
3. Há algo que eu deva estar ciente?
4. Você recomendaria essa opção?

Basicamente, eu daria boas -vindas a qualquer pensamento.

Answer 1

1. Não
2. Veja # 1
3. Você deve tomar cuidado com sobrecarga abstração padrão. Também é muito SQL Server com base em seu estado atual.
4. Você está usando SQL Server, então talvez. Se você estiver usando LINQ para outras coisas agora como dados sobre XML (grandes), objeto de dados, conjuntos de dados, então sim você deve poderia mudar para ter uma sintaxe de dados uniforme para todos eles. Como lagerdalek mencionado, se não está quebrado não consertá-lo. Desde o rápido olhar para .netTiers Application Framework, eu diria que se você já tem um investimento com essa solução parece dar-lhe muito mais do que uma simples camada de acesso a dados e você deve ficar com ela.

Da minha experiência LINQ to SQL é uma boa solução para projetos de pequeno porte médio. É um ORM que é uma ótima maneira de aumentar a produtividade. Também deve dar-lhe uma outra camada de abstração que lhe permitirá mudar o debaixo da camada para outra coisa. O designer no Visual Studio (e I Belive VS também Express) é muito fácil e simples de usar. Ele lhe dá a arrastar-soltar comum e edição baseada em propriedade dos mapeamentos de objeto.

Jason Jackson - O desenhador faz deixá-lo adicionar propriedades à mão, no entanto, você precisa especificar os atributos para essa propriedade, mas você fazer isso uma vez, isso pode levar 3 minutos, mais tempo do que o arrastar inicial da tabela em designer, no entanto, é necessário apenas uma vez por mudanças no banco de dados em si. Isto não é muito diferente de outros ORMs, no entanto, você está correto que eles poderiam fazer isso muito mais fácil, e encontrar apenas as propriedades que foram alteradas, ou até mesmo implementar algum tipo de ferramenta de refatoração para tais necessidades.

Recursos:

• Por que usar LINQ to SQL?
• Scott Guthrie em LINQ to SQL
• LINQ to SQL e Visual Studio Desempenho Atualização 2008
• comparações de desempenho LINQ to SQL / ADO / C #
• LINQ to SQL 5 Minute Overview

Note que LINQ paralelo está sendo desenvolvido para permitir muito mais maior desempenho em máquinas multi-core.

Answer 2

Eu tentei usar o LINQ to SQL em um projeto pequeno, pensando que eu queria algo que eu poderia gerar rapidamente. Corri para um monte de problemas no designer. Por exemplo, quando você precisa adicionar uma coluna a uma tabela que você tem basicamente para remover e adicionar novamente a definição da tabela no designer. Se você tiver definido as propriedades sobre a mesa, em seguida, você tem que re-definir essas propriedades. Para mim isso realmente abrandou o processo de desenvolvimento.

LINQ to SQL em si é bom. Eu realmente gosto da extensibilidade. Se eles podem melhorar o designer que eu poderia tentar novamente. Eu acho que o quadro iria beneficiar de um pouco mais funcionalidade destina-se a um modelo desconectado como desenvolvimento web.

Confira LINQ de Scott Guthrie a série SQL de posts para alguns grandes exemplos de como usá-lo.

Answer 3

NetTiers é muito bom para a geração de um pesado e DAL robusta, e nós usá-lo internamente para bibliotecas centrais e estruturas.

A meu ver, LINQ (em todas as suas encarnações, mas especificamente como eu acho que você está pedindo para SQL) é fantástico para acesso de dados rápida, e nós geralmente usá-lo para casos mais ágeis.

Ambas as tecnologias são bastante inflexíveis a alterações sem regeneração do código ou dbml camada.

Dito isto, usado corretamente LINQ 2 SQL é bastante uma solução robusta, e você pode até começar a usá-lo para o desenvolvimento futuro devido à sua facilidade de uso, mas eu não iria jogar fora o seu DAL atual para ele - se ele aint quebrou ...

Answer 4

A minha experiência me que o uso de conta usando linq que você pode fazer as coisas mais rápido, porém as ações reais para o banco de dados são mais lentos.

Então ... se você tem um pequeno banco de dados, eu vou dizer por ele. Se não, eu iria esperar por algumas melhorias antes de alterar

Answer 5

Eu estou usando LINQ to SQL em bastante grande projeto agora (cerca de 150 mesas) e que está trabalhando muito bem para mim. A última ORM que usei foi Ibatis e funcionou bem, mas tomou um monte de trabalho duro para obter seus mapeamentos feito. LINQ to SQL executa muito bem para mim e até agora provou ser muito fácil de usar fora da caixa. Não são definitivamente algumas diferenças que você tem que superar em transição, mas eu recomendo o uso.

Nota lateral, eu nunca usei ou ler sobre NetTiers por isso não vou desconto a sua eficácia, mas LINQ to SQL, em geral, tem provado ser um ORM extremamente viável.

Answer 6

A nossa equipa costumava usar NetTiers e achei que fosse útil. Mas ... a mais que usamos, mais encontramos dores de cabeça e dor pontos com ele. Por exemplo, quando você faz uma alteração para o banco de dados, você precisa re-gerar o DAL com CodeSmith que envolveu:

• re-geração de milhares de linhas de código em 3 projectos separados
• re-geração de centenas de procedimentos armazenados

Talvez existam outras maneiras de fazê-lo, mas isso é o que tínhamos que fazer. A re-gen do código-fonte foi ok, assustador, mas ok. A verdadeira questão veio com os procedimentos armazenados. Ele não limpar quaisquer procedimentos armazenados não utilizados por isso, se você tiver removido uma tabela de seu esquema e re-gened seu DAL, os procedimentos armazenados para que a tabela não são removidos. Além disso, este tornou-se bastante dor de cabeça para scripts de alteração de banco de dados onde tivemos para comparar a estrutura de banco de dados antigo para o novo e criar um script de alteração às instalações de atualização do cliente. Este script poderia correr para as dezenas de milhares de linhas de código SQL e se houvesse um problema de executá-lo, o que não invariavelmente, era, era uma dor para resolvê-lo.

Em seguida, a luz se acendeu, NHibernate como ORM. Ele certamente tem um tempo de ramp-up para ele, mas é bem a pena. Há uma tonelada de suporte para ele por isso, se há algo que você precisa fazer, mais do que provável que tem sido feito antes. É extremamente flexível e permite-lhe controlar todos os aspectos dela e então alguns. Ele também está se tornando mais fácil e mais fácil de usar. Fluente Nhibernate é ascendente e vindo como uma ótima maneira de se livrar dos arquivos de mapeamento XML que são necessários e NHibernate Profiler fornece uma excelente interface para ver o que está acontecendo nos bastidores para aumentar a eficiência e remover redundância.

Mover-se de NetTiers para NHibernate tem sido doloroso, mas em um bom caminho. Ele nos obrigou a mover-se em uma arquitetura melhor e re-avaliar as necessidades funcionais. NetTiers fornecido toneladas de código de acesso de dados, obter esta entidade pelo seu id, obter essa outra entidade por sua chave estrangeira, obter um tlist e vlist disto e daquilo, mas a maioria era desnecessário e sem uso. NHibernate com um repositório e personalizados genéricos repositórios apenas quando necessárias toneladas reduzidos de código não utilizado e realmente aumentar a legibilidade e confiabilidade.