ti-enxame.com

Quais são os critérios para avaliar um ORM for.NET?

Eu estou olhando para avaliar ORMs.

Eu usei SubSonic , Linq-to-SQL e Entity Framework . Eu tenho uma equipe de desenvolvedores que variam de juniores a seniores.

Quais são os critérios para avaliar um ORM for.NET?

30
Nickz

É uma pergunta carregada.
Existem muitas ORMs muito boas abordando o assunto com diferentes filosofias.
Nenhuma é perfeita e todas tendem a se tornar complexas assim que você se afasta do caminho de ouro (e às vezes até quando se apega a ela).

O que você deve se perguntar ao selecionar um ORM:

  1. O que ele precisa fazer por você?
    Se você já possui um conjunto de requisitos para o seu aplicativo, selecione o ORM que melhor corresponda a eles, em vez de um 'melhor' hipotético.

  2. Seus dados são compartilhados ou apenas locais?
    Grande parte da pelagem no ORM é causada pela maneira como eles lidam com a simultaneidade e as alterações nos dados no banco de dados quando vários usuários mantêm uma versão dos mesmos dados.
    Se o seu armazenamento de dados for para um usuário único, a maioria dos ORMs fará um bom trabalho. No entanto, faça a si mesmo algumas perguntas difíceis em um cenário multiusuário: como o bloqueio é tratado? O que acontece quando eu excluo um objeto? Como isso afeta outros objetos relacionados? O ORM está trabalhando próximo ao metal do back-end ou está armazenando muitos dados em cache (melhorando o desempenho às custas de aumentar o risco de staleness).

  3. O ORM está bem adaptado ao seu tipo de aplicativo? Um ORM específico pode ser difícil de trabalhar (muita sobrecarga de desempenho, difícil de codificar) se for usado em um serviço ou sentado em um aplicativo da web. Pelo contrário, pode ser ótimo para aplicativos de desktop.

  4. Você precisa desistir de aprimoramentos específicos do banco de dados?
    Os ORMs tendem a usar o conjunto de denominadores mais comuns do SQL para garantir que funcionem com muitos back-end de banco de dados diferentes.
    Todos os ORMs comprometem os recursos disponíveis (a menos que tenham como alvo específico um único back-end), mas alguns permitem implementar comportamentos adicionais para explorar aprimoramentos específicos disponíveis no back-end escolhido.
    Um aprimoramento típico específico do banco de dados são os recursos de pesquisa de texto completo, por exemplo; verifique se o seu ORM fornece uma maneira de acessar esses recursos, se você precisar deles.

  5. Como o ORM gerencia as alterações no modelo de dados?
    Alguns podem atualizar o banco de dados automaticamente dentro de uma certa medida, outros não fazem nada e você terá que fazer o trabalho sujo; outro fornece uma estrutura para lidar com mudanças que permite controlar as atualizações do banco de dados.

  6. Você pensa em acoplar seu aplicativo aos objetos do ORM ou prefere manipular POCOs e usar um adaptador para persistência?
    O primeiro é geralmente simples de manusear, mas cria dependências em seus objetos de dados específicos do ORM em todos os lugares; o último é mais flexível, à custa de um pouco mais de código.

  7. Você precisará transferir seus objetos remotamente?
    Nem todos os ORMs são iguais quando se trata de buscar objetos de um servidor remoto; observe atentamente o que é possível ou impossível fazer. Alguns são eficientes, outros não.

  8. Existe alguém para quem você possa pedir ajuda?
    Existe um bom suporte comercial? Quão grande e ativa é a comunidade em torno do projeto?
    Quais são os problemas que os usuários existentes estão enfrentando com o produto?
    Eles obtêm soluções rápidas?

Alguns ORMs que eu analisei:

  • XPO
    Do desenvolvedor Express: é pequeno e simples, centralizado em código. Eles o usam em sua estrutura de aplicativos eXpressApp .
  • NHibernate
    É gratuito, mas a curva de aprendizado é bastante acentuada. Muitas vantagens, mas é difícil encontrar o que é realmente relevante às vezes em toda a documentação fragmentada.
  • LLBLGen Pro
    projeto muito maduro, não o mais simples, mas muito pensamento foi colocado nele.
  • Estrutura da entidade
    Chegando la. Os últimos lançamentos são muito bons e o MS está ouvindo, embora ainda seja um pouco jovem comparado a outros ORMs mais maduros.
  • DataObject.Net
    Parece promissor, mas também é um pouco novo para arriscar um projeto importante no IMHO. Bastante ativo.

Existem muitos outros, é claro.

Você pode dar uma olhada no site controverso ORM Battle que lista alguns benchmarks de desempenho, embora você deva estar ciente de que a velocidade bruta não é necessariamente o fator mais importante para o seu projeto e que os produtores do site é DataObject.Net.

43
Renaud Bompuis

Estou usando NHibernate e achei muito bom.

No meu caso, vinculado a um banco de dados MS Sql, mas você pode se conectar a outros bancos de dados.

Não demora muito para começar a funcionar - basta mapear seu objeto para o modelo - eu uso um arquivo xml, mas você pode fazê-lo fluentemente em código. Existe uma grande comunidade e, pessoalmente, eu achei muito útil o trabalho de Ayende - eu uso o NHProf, que é uma ferramenta de criação de perfil sql.

Uso principalmente as funções prontas para uso - mapeamento direto de objetos, mas também uso a Hibernate Query Language, que é bastante fácil de entender.

14
Sam J

Infelizmente, nos meus últimos três empregos, tivemos três ORMs caseiros. Em cada caso, eles geralmente são sugados por várias razões.

Estive recentemente avaliando Entity Framework 4 e seu suporte ao POCO (um passo a passo agradável é aqui ) e estou realmente impressionado com o quão bem ele fica fora da minha cara e me faz sentir como se estivesse programando novamente, em vez de agrupar dados.

6
Jesse C. Slicer
6
Amir Rezaei

[AVISO LEGAL: Eu trabalho para o DevExpress]

Você pode ver capturas de tela de aplicativos típicos criados pelas estruturas de aplicativos do DevExpress aqui . Esta página também contém uma breve revisão de nossos produtos. Para obter informações mais detalhadas sobre por que , sugiro que você verifique as respectivas páginas de produtos em nosso site.

Quanto ao DevExpress XAF e XPO, aqui é uma boa explicação sobre por que escolher nossas estruturas de aplicativos. Além disso, fornecemos suporte e documentação, o que também é importante e vale a pena mencionar. Não hesite em contactar-nos em caso de dúvidas.

3
Dennis Garavsky

Eu gosto muito de Linq to Sql. É simples e tem um designer decente. No entanto, espero encerrá-lo em favor da estrutura da Entidade. Gostaria de aproveitar a capacidade de modificar os geradores para que eu possa ter objetos personalizados.

O maior benefício que eles têm sobre os outros (na minha opinião) é que eles estão fora da caixa com o VS. Isso também é negativo, pois você está à mercê do MS (consulte Linq to Sql).

3
Jeremy Roberts

Usamos NHibernate + Fluent NHibernate, com Linq-to-Sql em pequenos projetos. A razão para isso é:

1) (Não é o principal motivo) O NHibernate parece ter um fator de "respeito" mais alto entre os desenvolvedores (isso é verdade?),

2) Comparado ao linq-to-SQL, o nHibernate permite o mapeamento ORM entre objetos Db e entidades que não mapeiam 1 para 1,

3) Não comparamos extensivamente o nHibernate ao Entity Framework 4.0, mas aqui está uma boa comparação: http://ayende.com/blog/archive/2010/01/05/nhibernate-vs.-entity-framework- 4.0.aspx

o nHibernate tem uma curva de aprendizado bastante íngreme e seus mapas XML podem ser bastante detalhados, mas comece com a documentação do site do Fluent Nhibernate e faça o seu caminho para trás.

2
fjxx

Bem, não há "melhor" opção, mas eu diria que o Linq to SQL antigo e regular atende às suas necessidades. Não é um ORM "verdadeiro" por si só, mas é muito leve e oferece flexibilidade para escrever código sem estar ciente, se isso faz sentido. O que quero dizer é que você pode continuar escrevendo o código normalmente, sem ter que realmente estar ciente do Linq além de ter os arquivos dbml. Você ainda pode escrever abstrações sobre ele, usando os padrões Repository ou Gateway, e o L2S cumpre a função principal de um ORM, que é contornar a Incompatibilidade Objeto-Relacional.

O Entity Framework é um pouco pesado e, embora eu tenha me interessado um pouco, é mais "na sua cara" do que o Linq to Sql básico, mas o EF é muito mais um ORM verdadeiro do que o Linq. Eu examinaria todos os critérios que você está procurando em um ORM. É apenas porque você deseja evitar ter que escrever SQL bruto ou, pior ainda, ter centenas de Procedimentos Armazenados? Você precisa de alguns recursos extras que o Linq to Sql bruto não pode fornecer? Você precisa responder a essas perguntas, mas com base em seu breve requisito ("leve e fácil de usar"), acho que o Linq é um pouco mais fácil do que algo como o Subsonic e está embutido no Visual Studio.

1
Wayne Molina

Eu recomendaria que você desse uma olhada em DevExpress XPO . Isso, juntamente com DevExpress XAF facilitará a vida de qualquer desenvolvedor depois que sua curva de aprendizado for ultrapassada.

1
Yogi Yang 007

Não existe uma estrutura "melhor" do ORM porque todos eles têm combinações diferentes de pontos fortes e fracos e, geralmente, se os desenvolvedores optarem por melhorar uma área, há outras áreas que sofrem comparações (código primeiro vs primeiro modelo versus banco de dados primeiro).

Por outro lado, existem muitos muito bons, alguns dos quais serão mais adequados às suas circunstâncias pessoais e filosofia do que outros.


Edit: Pelo que vale a pena, atualmente estou usando o Linq to SQL - principalmente porque existe lá, em parte porque faz muito certo com o mínimo esforço e provavelmente progredirá para o Entity Framework novamente "porque está lá" (embora, similarmente, também exista muito sobre o EF4 que está certo, bem como algumas coisas que estão erradas). A preocupação, especialmente com o último, teria que ser desempenho, mas na maioria dos meus casos isso não é um problema enorme e a capacidade de executar dados dinâmicos e OData dos modelos (L2S e EF) traz benefícios consideráveis ​​para mim em termos de " vitórias baratas.

1
Murph

Tivemos boa sorte com o Entity Framework. Porém, nossa situação é algo incomum - fazemos a coleta de dados para a equipe de relatórios, para que eles realmente projetem o banco de dados. Obtemos o banco de dados e, em seguida, usamos EF para gerar as classes de acesso a dados a partir dele. Funciona muito bem para nós, mas apenas fazemos carregamentos de dados em massa, por isso não posso garantir o desempenho de um ambiente mais transacional.

1
TMN

NHibernate (+ FluentNHibernate) seria a opção padrão para mim. É muito flexível, extensível e robusto. Ele tem uma quantidade enorme de usuários e é mantido ativamente. A desvantagem é a curva de aprendizado acentuada.

LightSpeed ​​do MindScape é simples e amigável, mas ainda bastante flexível e capaz. Ele possui uma superfície de designer como L2S/EF e uma implementação UnitOfWork.

1
rmac

ECO :) É muito mais que um ORM, incluindo máquinas de estado e suportes executáveis ​​de OCL (a saber, EAL). Existe uma versão gratuita com uma limitação de 12 classes de domínio, que eu acho que deveria ser bastante interessante para pequenos projetos.

0
William