Ferramenta ORM - Crossroads?

Question

Oi eu parecem estar em uma encruzilhada ORM Ferramenta e gostaria de alguns conselhos de pessoas que enfrentaram um desafio semelhante. No passado eu ter sido usando CodeSmith com NetTiers modelos para gerar meu DAL tudo tem sido muito bom, no entanto eu decidi largar isso por uma razão ou outra.

Então, eu estou em uma encruzilhada e encontraram o seguinte: -

1. Eu olhei PLINQO (LINQ to SQL), que parece estar a fazer um grande trabalho no entanto com o Microsoft incerto do LINQ to SQL isso pode não ser uma boa escolha.
2. Linq to Entities - Isso ainda está em sua infância e eu posso estar errado, mas as pessoas estão reclamando sobre o inchaço e Procedimentos como armazenados
3. Eu olhei nHibernate, este talvez a melhor escolha, mas parece ser uma curva de aprendizado íngreme
4. O mesmo vale para LLBLGen
5. Subsonic -? Não tenho certeza sobre este
6. ficar com o NetTiers experimentadas e testadas, esquecer o inchaço, se esqueça de que você é forçado a usar a biblioteca da empresa, esquecer a dinâmica sql que cria, se esqueça de que o seu é quase nenhuma atividade nos fóruns, esqueça isso e usá-lo!

Já própria CodeSmith e não querem comprar qualquer outra coisa, o código gerado trabalho deve em modo de confiança média ...

Pode haver outros que eu ter perdido. Estou à procura de respostas que explicam por que a ferramenta ORM vale a pena olhar.

Graças Richard

Answer 1

Eu costumava .netTiers me no último projeto. mas o que eu estou trabalhando no momento estamos tentando Linq 2 entidades. Você está certo sobre Linq2EF não ser amadurecer. Fazemos cadela sobre isso o tempo todo é por isso que usamos T4 modelos que geram código do arquivo EDMX. Nós também mudou esses modelos por isso temos a Business Objects, Interfaces para injecção e DAL + DAO. Estamos felizes em como ele funciona agora. A coisa boa é que podemos usar LINQ contra Entidades.

Caso contrário, eu também sugiro Fluente nHibernate ( ligação ) para você. Foi uma das coisas que nós também considerados. Mas você vai ter que escrever muitas coisas em seu próprio país. Não é como você está acostumado em .netTiers onde todo o código é gerado para você.

Desde Subsonic 3 ( ligação ) é apenas cerca de uma semana de idade eu sugiro que você Confira. Baseado no que eu vi parece muito promissor. E ele usa T4, para que possa cortar & cortar-lo para atender às suas necessidades.

Answer 2

Eu tentei alguns para algumas semanas e finalmente resolvido com NHibernate. É muito fácil de personalizar. Há uma curva de aprendizagem e é preciso um pouco mais de tempo para configurar que algo como LINQ to SQL, mas o lado positivo disto é que não parece como mágica. Você vai entender como ele funciona e será capaz de personalizá-lo exatamente para atender às suas necessidades. A comunidade também é muito bom e há uma grande quantidade de documentação disponível. Parece-me ser um bom equilíbrio entre um moderno ORM (Sem geração de código, pode usar POCO), e maturidade.

Answer 3

Você poderia tentar DataObjects.NET. Esta abordagem usa ORM "Code-First", suporta DB esquema atualizar e LINQ. Marque esta breve descrição http://www.x-tensive.com/Products/DO/ .

Answer 4

Eu acho que as duas ferramentas ORM mais respeitáveis ??e fortes agora são nHibernate e LLBLGen Pro .

nHibernate = orientada impulsionado Muito domínio.

LLBLGen Pro = Data Driven orientada.

Ambos são excelentes, e para cada projeto, dependendo isso de uma natureza pode ser mais apropriado em relação ao outro. Ele também vem frequentemente para baixo a escolha e preferências pessoais ou mesmo a cultura da equipe de desenvolvimento.

Como eu disse embora, no final, em geral eles são excelentes e ambos têm suas pequenas vantagens / desvantagens.

Answer 5

Por razões para usar um ORM aqui está um link para um blog por Glenn Bloco que diz tudo realmente. Quanto à minha experiência, há pouco mais de um ano atrás, eu estava olhando para usar um ORM e eu escolhi NHibernate.

Persistência para mim é um problema resolvido, além de alguma forma de mapeamento do meu modelo de domínio aos meus dados relacionais é algo que eu não precisa se preocupar com mais. Olhei para LINQ to SQL, mas ele simplesmente não me deu controle suficiente sobre a forma como os dados foram mapeados para meus objetos e o Entity Framework não foi onde perto maduro o suficiente para o meu gosto. Outro grande projeto alguns da minha equipe estavam trabalhando em NetTiers utilizados e CodeSmith e como você diz, o inchaço, a geração de código (e a enorme quantidade dele) me fez sentir um pouco quesy. No final, eu escolhi NHibernate porque para mim, é um dos mais maduro ORMs lá fora, e forneceu recursos que não só apoiam um modelo de objeto de textura fina, mas foi construído em consulta instalações e inerentemente aborda outras questões de desempenho tal como cache.

Sim, eu vou admitir que a curva de aprendizagem é bastante íngreme, mas se você investir o tempo, os benefícios que você vai sair dela são enormes. Os blogs de Ayende Rahien e Fabio Maulo são uma mina de informações sobre NHibernate. Há algum apoio LINQ para NHibernate através deste LINQ provedor mas Steve Strong está colocando recursos em conjunto, que irá fornecer suporte LINQ completa em NHibernate. Então, é tudo ir para NHibernate, mas no final do dia, depende do que você está mais confortável com.