nHibernate contre LLBLGen Pro

J'ai utilisé les deux. J'ai d'abord été vendu sur nHibernate et a refusé d'essayer quoi que ce soit d'autre, même si je savais que sur les autres options.

Avec LLBLGen Pro, j'étais sceptique, mais très vite vu les avantages. Je n'ai pas totalement abandonné nHibernate. Je vais continuer à garder un int dans ma "boîte à outils". J'ai trouvé LLBLGen utile dans certains cas, en particulier lors de l'interaction avec une base de données qui existe déjà et que vous n'avez pas le choix de re-conception. Il faut moins d'une heure (en fonction de la taille de la base de données de cours) pour générer mon LLBLGen Objets de l'Entité de la base de données, plutôt que d'avoir à coder tout ça manuellement avec nHibernate, ET ne les mappages. nHibernate est manquant une belle interface graphique pour créer des mappages. Ce fait est d'autant plus important lorsque la base de données est énorme avec des milliers de tables que vous avez besoin pour éventuellement accéder à votre demande.

Bien que LLBLGen est plus d'une Couche d'Accès aux Données du générateur (Et je ne suis pas habituellement un fan de DAL générateurs), il a beaucoup de caractéristiques d'un "vrai ORM" outil aurait. À mon avis, il a le meilleur des deux mondes. Une fois que vous commencez à travailler avec elle, vous commencez à réaliser qu'il est très souple et extensible. Une partie que j'aime beaucoup, c'est qu'il m'est possible de créer des classes partielles pour l'généré objets de l'entité, où je peux code dans ma logique d'entreprise, ainsi que la validation.

La génération de code est basé sur un modèle de sorte que vous avez le plein contrôle sur le code qu'il génère. Avec nHibernate je me retrouve à écrire certains de le même genre de code encore et encore. Avec LLBLGen je peux générer et apprendre à se concentrer sur la logique métier et les problèmes plus rapidement.

Pour quelqu'un qui vient de commencer à utiliser l'ORM type d'outils, vraiment, je recommande de commencer avec LLBLGen, parce que nHibernate peut être écrasante. Et à la fin vous aurez obtenu le même résultat (Plus ou moins).

Edit #1: LLBLGen a désormais 100% de prise en charge de LINQ. (Donc si vous aimez LINQ to SQL pour cette raison) plus LLBLGen peuvent prendre en charge plusieurs bases de données, où LINQ to SQL est seulement pour la Base de données Microsoft SQL.

Edit #2:
Selon le Graviton vous pouvez utiliser CodeSmith de faire une partie du code à générer pour vous pour nHibernate. C'est vraiment cool, mais pour un nouveau venu à l'ORM, je voudrais encore vous recommandons de LLBLGen. Pour moi, c'est l'ajout de plus de dépendances où LLBLGen a tout dans un seul paquet. Aussi, comme je l'ai dit avant que la courbe d'apprentissage est beaucoup moins raide et vous obtiendrez les mêmes avantages, qui vous aidera aussi à l'aise dans nHibernate si jamais vous décidez d'y aller.

J'ai tapé jusqu'à une assez longue réponse avant de réaliser ce était un peu vieille question. Oh bien. C'est toujours très pertinentes.

Vous avez réduit votre liste pour les deux meilleurs candidats pour un ORM dans le .Monde NET. J'ai peu d'expérience avec soit, mais j'ai beaucoup lu sur les avantages et les inconvénients des deux. Ils servent vraiment un peu différents besoins de différentes manières.

Dans la prochaine LLBLGen Pro 3.0, Frans Bouma a parlé de l'ajout de fonctionnalités pour générer des mappages NHibernate. Donc, il n'est même pas nécessairement l'un ou l'autre/ou d'une décision.

Si vous voulez faire la "première classe" de la conception (par opposition à la "base de données" de la conception), NHibernate est assez bien votre meilleure option en ce moment (ni LLBLGen Pro, ni Cadre de l'Entité en charge ce mode, bien que cela sonne comme une Entité Cadre de l'amélioration de ce soutien dans la prochaine version).

NHibernate et LLBLGen Pro à la fois travailler dur pour bien travailler avec les bases de données héritées laquelle vous ne pouvez pas changer et vivre avec. C'est leur force. Ils travaillent également avec Linq. Ils ont tous deux également en charge certains montant de modélisation graphique, bien que LLBLGen Pro est de loin supérieure à cet égard (ActiveWriter pour NHibernate se sent comme à la LinqToSql designer de Visual Studio, mais ce n'est pas aussi riche en fonctionnalités).

LLBLGen Pro a beaucoup plus forte génération de code capacités, mais trop de génération de code peut conduire à des compromis la testabilité et la maintenabilité (un petit tweak peut causer d'énormes quantités de code à besoin de nouveaux essais).

Alors que NHibernate veut vous aider à travailler à travers assez complexe de mappage objet/relationnel des scénarios comme celui de l'héritage de classe, LLBLGen Pro est vraiment juste d'exposer votre base de données en tant que couche de données et de business objects de manière très rapide.

Si vous pouvez acheter LLBLGen Pro et avez un peu de temps, je voudrais essayer les deux et de voir celui qui mieux répond à vos besoins. L'apprentissage des deux Orm est bon pour votre cv dans tous les cas.

Donc, à la fin, je dirais que c'est de la situation. Le coût de NHibernate et son manque de sérieux défauts de faire un joli cas dans la majorité des situations.

J'ai utilisé nHibernate, LLBLGen Pro, une coutume de la couche de données à partir de ma société de conseil, de la Bibliothèque d'Entreprise, et LINQ. LLBLGen est de loin mon préféré, et il permet l'écriture d'une couche de gestion qui peuvent parler à différents types de bases de données en utilisant le même code de base de données de l'indépendance! Une autre fonction incroyable est qu'il permet de multiples connexions à des bases de données différentes. Ceci est très utile lorsque dans une grande entreprise et un système qui est écrit dans Sql Server et les autres vous avez à l'interface avec est dans Oracle.

LLBLGen Pro est un produit étonnant soutenu par Frans qui est très actif et travaille dur pour résoudre les problèmes. LLBLGen est comme PhotoShop, c'est un outil incroyable et qui peut faire d'incroyables effets dans les mains de quelqu'un qui sait comment l'utiliser. Et comme tout outil qui permet d'économiser beaucoup de temps, il faut une semaine ou deux pour apprendre à l'utiliser, mais vous permettra d'économiser des mois plus tard sur votre projet.

Non seulement d'accélérer la DAL génération à côté de mon application, il est également facile de créer des requêtes dans la couche de gestion et de l'envoyer à la couche de présentation. Il fait, il est facile de créer une entreprise de classe de l'application.

Si on veut vraiment utiliser nHibernate, commencer avec LLBLGen Pro et de générer de la nHibernate code. Si, plus tard, sur votre département décide de passer de nHibernate LINQ, vous êtes couvert. Vous souhaitez passer du Serveur Sql pour Oracle? C'est possible et relativement facile avec LLBLGen alors qu'avec codées manuellement nHibernate code, vous devez réécrire tout ce qui est pratiquement impossible coût justifier.

Frans a également été disponible et a répondu à certaines de mes questions.

Pour moi ça se résume à la base de données centrée sur le (LLBLGen Pro) par rapport au modèle de domaine centric (NHibernate).

Depuis que je suis DDD/OO guy, le choix a toujours été très facile pour moi, mais je ne vois pourquoi LLBLGen Pro est populaire.