Dicas para migrar do XPO para LINQ to SQL

Question

Eu sou um usuário de longa data da biblioteca DevExpress XPO. Ele tem muitas características grandes, mas há alguns pontos fracos:

1. Ao salvar um objeto existente, todas as propriedades são enviados em uma consulta de actualização; as alterações são controladas em uma base per-objeto, e não por propriedade.
2. de bloqueio optimista é feito sobre uma base por objecto, em vez de por coluna.
3. Quando ocorre uma excepção de bloqueio optimista, nenhum contexto está previsto que descreve a natureza do conflito; sua única resposta real é a falhar a operação ou reproduzi-lo e tente novamente em um loop.
4. Suporte LINQ para XPQuery é muito fraco (pelo menos em 8.1, que estamos usando). Assim, muitas vezes você é forçado a usar XPView, que não é tipo seguro, ou XPCollection, que pode voltar colunas que você não precisa necessariamente.

Depois de ler sobre como LINQ to SQL implementos optimisting bloqueio e manipulação de conflitos de atualização, I foi vendido! Eu gosto de como ele implementa em nível de coluna bloqueio otimista e não precisa adicionar uma coluna à tabela. Ser capaz de inspecionar e lidar com a natureza exata dos conflitos é grande. E o fato de que eles acompanhar as mudanças por coluna deve fazer suas consultas de atualização muito mais eficiente.

Claro, eu ainda não usado LINQ to SQL em aplicações reais, então eu não sei se compara na realidade. Além disso, estou incerto sobre se ele tem análogos para algumas das características que desfrutamos com XPO, tais como:

1. atualizações de esquema automáticas (acreditamos no projeto objeto condução estrutura de banco de dados e não o contrário, e isso simplifica muito a implantação de software)
2. Duas opções para como a herança é implementada (relações de tabela mesmo mesa ou um-para-um)
3. Suporte para armazenamento em memória (embora eu suponho que poderíamos substituir LINQ to Objects em nossos testes de unidade)
4. personalização provedor de armazenamento (que nos permitiu adicionar suporte NOLOCK às nossas perguntas XPO)

Nós vamos estar fazendo uma migração parcial exploratória onde estará temporariamente usando os dois ORMs para diferentes partes do nosso código. Algum de vocês já teve a experiência do mundo real com tanto XPO e LINQ to SQL? Como eles se comparam na prática? Especificamente, você sabe de quaisquer recursos que LINQ to SQL não tem que fornecer desafios para a migração de código?

Oh, e eu deveria sequer se preocupam com LINQ to Entities? Ele parece muito mais complicado do que qualquer coisa que precisamos.

Answer 1

Estou triste que eu não recebi nenhuma resposta da comunidade, mas aqui está meus pensamentos até agora. Eu tive a chance de experimentar o LINQ to SQL e ADO.NET Entity Framework por um tempo em diferentes projetos, e eu sinto que ADO.NET Entity Framework seria melhor preencher as nossas necessidades. Quanto ao específicas de XPO características que eu estava esperando para manter:

1. atualizações de esquema automático terá que ir uma vez que converter. É um aborrecimento menor, mas existem alguns benefícios para manter este separadamente.
2. ADO.NET Entity Framework tem um monte de opções de mapeamento de dados; os diferentes modelos de herança parece ser suportado.
3. Para o armazenamento em memória, eu ainda estou inseguro como bem suportado este é. Parece haver um provedor ADO.NET SQLite que é compatível com o Entity Framework, e SQLite pode fazer o armazenamento em memória, por isso, em teoria, os testes de unidade poderia usar uma seqüência de conexão diferente especificando o banco de dados in-memory. Esperemos que é fácil; caso contrário, escrever testes de unidade será muito difícil de fazer sem um monte de trabalho (abstraindo uma interface de repositório, etc).
4. Eu não olhei para personalização provedor ainda. Tentei arquiteto do sistema de tal forma que não teremos o máximo de dados compartilhados entre os serviços como antes, então talvez nós não precisamos de todas essas declarações WITH (NO LOCK) que eu precisava em sistemas anteriores. Ou talvez SQL Server 2008 melhorou os seus mecanismos de bloqueio de modo que não irá encontrar os mesmos problemas de bloqueio.

Answer 2

Assim que você fez migrar sua aplicação a partir XPO para Linq2Sql, não é? Estive jogando com XPO como parte de XAF também, honestamente prefiro Linq2Sql / EF para XPO, mas uma vez que está intimamente ligado em XAF então eu não tenho outra escolha. Nós vamos usar XAF para acelerar a implementação da interface do usuário de um nosso produto, acho XAF faz o seu trabalho muito bem, mas eu estou realmente preocupado com XPO.

Obrigado,