Você usaria LINQ to SQL para novos projetos?

Question

Eu estive investigando o que camada de dados para usar para um novo projeto baseado na web que eu estou projetando e eu estou muito interessado em olhar para incorporar LINQ to SQL. Sua aparente simplicidade, flexibilidade e designer de apoio realmente agrada eo tie-in implícita para o SQL Server é bom.

No entanto, foi anunciado recentemente que LINQ to SQL vai tomar um banco traseiro para o Entity Framework agora que ele foi passado para a equipe ADO.NET ( http://blogs.msdn.com/ adonet / Arquivo / 2008/10/29 / update-on-linq-to-sql-and-LINQ para entidades de roadmap.aspx ). Claro, ele será suportado no futuro, mas é improvável que ele vai ver muito mais trabalho de desenvolvimento.

Com isto em mente, você recomendaria me usando essa tecnologia para o meu projeto ou vale a pena tanto selecionar um ORM alternativa (nHibernate?) Ou codificação manualmente uma DAL genérico?

O projeto em si é ASP.NET e SQL Server 2005/2008 base e possivelmente irá usar MVC, embora ele ainda está em beta. É um projeto pessoal, o banco de dados não será excessivamente complexa e vai ser usado principalmente como um protótipo de olhar para .NET futura tecnologia. Eu estaria baseando projetos futuros sobre o que eu aprender com este embora, então as escolhas que eu fizer vai afetar soluções maiores por vir.

E sim, eu percebo que a Microsoft provavelmente vai trazer uma nova tecnologia de acesso de dados inteiro amanhã de qualquer maneira! ;)

Answer 1

Bem, é principalmente coberto de respostas aqui (alguns pontos de vista interessantes também) já, mas eu vou dizer outra vez de qualquer maneira ..

LINQ to SQL (L2S) é muito versátil, mas ele se sente um pouco demasiado básica do meu ponto de vista. Na maioria dos casos ele faz um trabalho bom em fazer coisas simples, mas assim que você pede um pouco mais do mesmo, torna-se caro. Isso não é de todo uma coisa ruim. Eu realmente acho que o LINQ to SQL realmente suppliments o Entity Framework bem.

Leve Auto paginação com LinqDataSource por exemplo. Se você não especificar Order By / Group By, então é bastante econômica. Lance ordenação ou agrupamento na mistura e você começa a ter um pico de performance (se torna muito falador). Você, então, praticamente tem que escrever sua própria implementação de paginação (que não é terrivelmente difícil, admito).

Eu serei o primeiro a admitir que L2S tem a vantagem sobre o Entity Framework em termos da qualidade do T-SQL gerado (eu deveria, desde L2S é construído especificamente para a consulta SQL Server) e conceitualmente e symantically, muito do LINQ to SQL é semelhante a EF, mas onde você bater na parede é na expansão necessidades e consideração para requisitos de implementação mais complicada.

Se eu fosse começar do zero e optar por dedicar o tempo de desenvolvimento pessoal, eu escolheria o Entity Framework. Curiosamente, eu estou trabalhando em um projeto no momento que usa L2S e está sendo projetado para escalar punho nad pesadas cargas, mas quando nós batemos alguns dos requisitos mais "criativas", que muitas vezes são forçados a se expandir em SQL metal (por exemplo, muitos-para-muitos relacionamentos).

Então .. enfim .. eu abordá-lo assim:

a) aprender LINQ to SQL como uma introdução (para padrões ORM da Microsoft e tecnologia) .. você fica familiarizado com a maioria dos fundamentos que são compartilhados com o Entity Framework, e um gosto de consultar estilo LINQ (um gosto adquirido se você tem um fundo em T-SQL)

b) uma vez que você tem uma alça sobre LINQ to SQL, eu recomendo saltar para o Entity Framework para aprender os benefícios adicionais (eSQL etc)

c) Implementar uma prova de conceito do projeto em ambos e comparar os resultados.

Answer 2

Escolha NHibernate. Ele vai ficar em torno de algum tempo como um conceito ou o ORM real. Por isso, será útil para aprender ambos.

Answer 3

IMO, essa coisa toda foi realmente fora de proporção.

Microsoft não disse que LINQ to SQL estaria morto. Eles mais indicado que seria incorporada pela Entity Framework.

gostaria de focar usando Entity Framework como uma solução, sabendo que grande parte do LINQ to SQL será lançado para ele.

Não há realmente muita diferença no momento de qualquer maneira. A maior queixa é que o Entity Framework não é peso-leve. Será que isso realmente importa, desde que você tem uma boa separação entre as camadas?

Answer 4

L2S é, IMHO, perfeitamente bem do jeito que está e como você disse, não vai a lugar nenhum. O trabalho corporação I para a tornou nosso padrão para acesso a dados e estamos a usá-lo para tudo, desde pequenos aplicativos de nicho 5 usuário para aplicativos corporativos 1000 usuários com grandes resultados.

Answer 5

Confira SubSonic:

http://subsonicproject.com/

Answer 6

Eu acho que os objetivos da EDM nosso muito maior do que aqueles de LINQ to SQL. Se você está procurando um ORM simples, então eu acho que o LINQ to SQL é o caminho a percorrer. Se você planeja construir em classes que têm uma estrutura de herança em relação às tabelas de banco de dados que têm uma estrutura relacional e fazer outros mapeamentos avançados, em seguida, EDM pode ser uma boa escolha.

Answer 7

Vale a pena mencionar que este site é construído usando LINQ to SQL. Jeff falou sobre a usá-lo no podcast StackOverflow.

Answer 8

L2S é uma tecnologia incrível, e eu nunca iria voltar para ADO de idade.

Mas como você mencionou, ele está tomando um banco traseiro para L2E. L2S é mais do que capaz e eu fizeram várias aplicações com ele e foram incrivelmente satisfeitos. Mas ouvir que ele não será mais posto avançado uma faca no meu lado. Então eu fui para verificar L2E e é quase a mesma coisa quando se trata de interação SQL, e de muitas maneiras eu acho mais fácil, para não mencionar mais eficiente com seu manuseio relação. Com tais semelhanças, parece lógico para escolher L2E.

Eu escrevi um post sobre como fazer o interruptor e comparando os dois quadros: http://naspinski.net/post/Getting-started-with-Linq-To-Entities.aspx

Eu quase posso garantir que você vai ser feliz com qualquer uma destas estruturas, eles são uma dádiva de Deus para o desenvolvimento. A simplicidade e erro evasão é inigualável. Eu pessoalmente se inclinar para L2E como será desenvolvido de forma mais agressiva thatn L2S.

Answer 9

Eu uso L2S fortemente em meu projeto web atual e acredito que o maior hangup você encontrará está em conflito documentação sobre a melhor maneira de fazer o desenvolvimento de banco de dados n-tier.

Em primeiro lugar e acima de tudo o que você precisa para perceber inicial é, DataContext objetos são feitos para durar apenas enquanto unidade de trabalho , período. Além disso, DataContext de são apátridas. Uma vez que você vir a enfrentar estes dois princípios, usando LINQ em um ambiente n-tier começa a trabalhar bem.

Por outro lado, você verá um número de pessoas recomendando algumas maneiras muito muito muito ruim para usar Linq. Nunca faça o seu estática DataContext, este é um erro que eu fiz no início e funcionou maravilhas até que não funcionou, então era absolutamente horrível com cruzamento de dados incorretos entre sessões diferentes, etc. Simplificando, este é talvez o maior mais gigantesco no-no de usar Linq e deve ser escrito em grandes letras em negrito em cada documento. Além disso, persiste um DataContext em uma variável de sessão é um igualmente má idéia.

A única outra grande desagradável Corri para com LINQ é ao fazer uma atualização desconectado, você precisa usar os mesmos DataContext em toda a chamada. Por exemplo:

    public static void UpdateUser(UserLibrary.User user) {
        using (UserLibraryDataContext dc = new UserLibraryDataContext(_conStr))
        {
            UserLibrary.User newUser = (from user2 in dc.Users where user2.UserID == user.UserID select user2).FirstOrDefault();
            newUser.Email = user.Email;
            newUser.FirstName = user.FirstName;
            newUser.LastName = user.LastName;
            dc.SubmitChanges();
        }        

Você não pode simplesmente passar em um usuário criado em um datacontext diferente e esperar Update para o trabalho, a menos que você definir DataContext.ObjectTrackingEnabled = false, que eu não recomendo. Em vez disso, dentro dos mesmos DataContext você deve recuperar o objeto existente, atualizar seus valores, em seguida, enviar que as mudanças. Mantenha todos como tarefas dentro do mesmo DataContext.

Eu recomendaria L2S, porém, uma vez que você passar por cima de algumas questões incómodas (como o acima), é uma grande tecnologia e definitivamente uma poupança de tempo. No entanto, gostaria de recomendar a fazer um wrapper fino em torno de seu DAL, então você pode mudar facilmente. Estou pensando (por razões econômicas) portando uma parte do meu código para usar OpenAccess ORM -> MySQL para uma parte do meu acesso a dados, e com uma camada adequadamente definidos, essa tarefa só deve me levar algumas horas.

Answer 10

Eu concordo com Echostorm. L2S é bom para suas necessidades. E é muito fácil trabalhar com ...

Answer 11

Se você projetar seu aplicativo corretamente e isolar sua camada de acesso a dados bem, você deve ir com L2S. Pelo que deduzo de seu post, que não é um projeto grande, então L2S deve atender às suas necessidades muito bem, enquanto planície ADO.NET idade é apenas um não-não, e Entity Framework, é ... simplesmente não usá-lo , Está bem? Enfim, se você isolar bem o seu DAL, você pode trocar L2S para outra coisa no futuro, se o projeto cresce. e mesmo se L2S não vai a lugar nenhum, não vai a lugar nenhum. MS parou de investir nele, mas isso não vai se tornar obsoleta ou algo assim, por isso é ainda um investimento seguro. Como alternativa, você deve avaliar NHibernate, que é simples e amadurecer.