framework de persistência?

Question

Eu estou tentando decidir sobre a melhor estratégia para acessar o banco de dados. Eu entendo que esta é uma pergunta genérica e não há uma única resposta boa, mas vou dar algumas orientações sobre o que eu estou procurando. Nos últimos anos, temos vindo a utilizar o nosso próprio framework de persistência, que, embora limitado tem servido bem. No entanto ele precisa de algumas melhorias importantes e eu estou querendo saber se eu deveria ir por esse caminho ou usar um dos quadros existentes. Os critérios que eu estou procurando, em ordem de importância são:

1. O código do cliente deve trabalhar com objetos limpos, largura nenhum conhecimento de banco de dados. Ao utilizar nossa estrutura de costume os olhares código do cliente, como:

   sessão SessionManager = new SessionManager (); Pedido = session.CreateEntity (); order.Date = DateTime.Now; // definir outras propriedades OrderDetail detalhe order.AddOrderDetail = (); detail.Product = produto; // Outras propriedades

   // confirmar todas as alterações agora session.commit ();

2. deve o mais simples possível e não "muito flexível". Precisamos de uma única maneira de fazer a maioria das coisas.

3. Deve ter um bom suporte para programação orientada a objeto. Deve lidar com um-para-muitos e muitos-para-muitos relações, deve lidar com a herança, o suporte para o carregamento lento.
4. Configuração é o preferido para ser baseado em XML.

Com o meu conhecimento atual vejo estas opções:

1. Melhorar a nossa estrutura atual -. O problema é que ele precisa de uma boa dose de esforço
2. ADO.NET Entity Framework -. Não tem um bom entendimento, mas parece muito complicado e tem críticas ruins
3. LINQ to SQL - Não tem boa movimentação de práticas orientadas a objetos
.
4. nHibernate -. Parece uma boa opção, mas alguns usuários relatam muitos erros arcaicos
5. SubSonic - A partir de uma breve introdução, parece muito flexível. Eu não quero isso.

O que você irá sugerir?

EDIT:

Obrigado Craig para a resposta elaborada. Eu acho que vai ajudar mais se eu dar mais detalhes sobre o nosso quadro personalizado. Eu estou procurando algo semelhante. Isto é como o nosso quadro personalizado funciona:

1. É com base em conjuntos de dados, então a primeira coisa a fazer é configurar o DataSets e consultas de escrita que você precisa lá.
2. Você cria um arquivo de configuração XML que especifica como as tabelas DataSet mapeiam para objetos e também especificar associações entre eles (suporte para todos os tipos de associações). ferramenta personalizada 3.A análise da configuração XML e gerar o código necessário. aulas 4.Generated herdar de uma classe base comum.

Para ser compatível com nossa estrutura de banco de dados deve atender aos seguintes critérios:

1. Cada tabela deve ter uma única coluna como chave primária.
2. Todas as tabelas devem ter uma chave primária do mesmo tipo de dados gerados no cliente.
3. Para herança alça única herança única tabela é suportado. Além disso, o arquivo XML, quase sempre oferece uma única maneira de conseguir alguma coisa.

O que queremos apoiar agora é:

• Remover a dependência de conjuntos de dados. código SQL deve ser gerado automaticamente, mas o quadro não deve gerar o esquema. Eu quero controlar manualmente o esquema DB.
• Um apoio mais robusto para hierarquias de herança.
• Integração opcional com LINQ.

Espero que seja mais claro agora que eu estou procurando.

Answer 1

Melhorar o nosso quadro actual - O problema é que ele precisa de uma boa dose de esforço

Na sua pergunta, você não deu uma razão por que você deve reescrever a funcionalidade que está disponível a partir de tantos outros lugares. Gostaria de sugerir que reinventar um ORM não é um bom uso do seu tempo, a menos que você tem necessidades exclusivas para o ORM que você não especificou na sua pergunta.

ADO.NET Entity Framework

Estamos usando o Entity Framework no mundo real, software de produção. Complicado? Não mais do que a maioria dos outros ORMs, tanto quanto eu posso dizer, o que quer dizer, "bastante complicado." No entanto, é relativamente novo, e como tal há menos experiência da comunidade e documentação do que algo como NHibernate. Assim, a falta de documentação pode muito bem fazê-lo parecer mais complicado.

O Entity Framework e NHibernate têm abordagens distintas para o problema da redução do fosso objeto-relacional. Eu escrevi sobre isso em um bom bocado mais detalhes em este post . Você deve considerar qual abordagem faz mais sentido para você.

Tem havido uma grande quantidade de comentários sobre o Entity Framework, tanto positivas como negativas. Alguns dos que é bem fundamentada, e alguns dos parece vir de pessoas que estão empurrando outras soluções. As críticas bem fundamentadas incluem

• falta de apoio POCO. Este não é um problema para algumas aplicações, é um problema para os outros. apoio POCO provavelmente será adicionado em uma versão futura, mas hoje, o melhor a pode oferecer Entity Framework é IPOCO.
• Um arquivo de mapeamento monolítico. Este não foi um grande problema para nós, desde a nossa metadados não está em fluxo constante.

No entanto, algumas das críticas parecem-me perder a floresta para as árvores. Ou seja, eles falam sobre características que não seja a funcionalidade essencial de mapeamento objeto relacional, que o Entity Framework provou-nos fazer muito bem.

LINQ to SQL - Não tem boa movimentação de práticas orientadas a objetos

Eu concordo. Eu também não gosto o foco SQL Server.

nHibernate -. Parece uma boa opção, mas alguns usuários relatam muitos erros arcaicos

Bem, a coisa agradável sobre NHibernate é que há uma comunidade muito vibrante em torno dele, e quando você encontrar esses erros esotéricos (e acreditem, o Entity Framework também tem sua parcela de erros esotéricos, que parece vir com do território) muitas vezes você pode encontrar soluções muito facilmente. Dito isto, eu não tenho muita experiência pessoal com NHibernate além da avaliação que fizemos que nos levou a escolher o Entity Framework, então eu vou deixar outras pessoas com comentário experiência mais direta sobre isso.

SubSonic - A partir de uma breve introdução, parece muito flexível. Eu não quero isso.

SubSonic é, naturalmente, muito mais do que apenas um ORM, e os usuários SubSonic tem a opção de escolher uma implementação de ORM diferente em vez de usar ActiveRecord do SubSonic. Como um framework de aplicações web, eu consideraria isso. No entanto, sua característica ORM não é sua razão de ser, e eu acho que é razoável suspeitar que a parte ORM de SubSonic vai ter menos atenção do que o ORM dedicado enquadramentos fazer.

Answer 2

LLBLGen fazer muito boa ferramenta ORM, que vai fazer quase tudo o que você precisa.

Answer 3

iBATIS é o meu favorito porque você obter uma melhor grão de controle sobre o SQL

Answer 4

Developer Express Persistência objetos ou XPO como é mais conhecido. Eu usá-lo para 3 anos. Ele fornece tudo que você precisa, exceto que ele é comercial e você amarrar-se com outra (empresa individual) para o seu desenvolvimento. Fora isso, Developer Express é um dos melhores fornecedores de componentes e de enquadramento para a plataforma .NET.

Um exemplo de código XPO seria:

using (UnitOfWork uow = new UnitOfWork())
{
  Order order = new Order(uow);
  order.Date = DateTime.Now();
  uow.CommitChanges();
}

Answer 5

Eu sugiro dar uma olhada na ActiveRecord do Castelo Eu não tenho experiência de produção com ele, eu apenas brinquei com seu aplicativo de exemplo. Parece realmente fácil de trabalhar, mas eu não sei bem o suficiente para saber se ele se encaixa todas as suas necessidades