S'il vous plaît recommander .NET ORM pour le développement N-Tier

Pourquoi ne pas essayer NHibernate ?

Je recommanderais l'entité framework v4. Il s'est amélioré de manière spectaculaire depuis V1 et prend en charge tout ce dont vous avez besoin sauf étant open source:

1. EF prend en charge une très grande variété de mappages, notamment TPH, TPT et TPC. Prend en charge POCO mappage, vous permettant de garder votre logique de persistance séparée de votre domaine.
2. EF a un support complet et excellent pour LINQ, permettant une interrogation vérifiée facile à utiliser et de compilation de votre modèle. EF Futures Composants tels que CODE-SEULEMENT Simplifiez travailler avec EF encore plus, fournissant un code purs, vérifiant le temps de compilation, API fluide pour définir votre modèle. En optant pour la convention sur la configuration, le code ne peut que réduire radicalement votre temps de conception de modèle, vous permettant de vous mettre en affaires sans tous les tracas de Tinkering avec un modèle visuel et plusieurs fichiers de mappage XML.
3. Il est gratuit dans le cadre de .NET 4. (Désolé, la préférence open source ne peut pas être rencontrée ici.)
4. EF fournit une excellente solution N-Tier oob via Entités auto-suivantes
   • Les informations d'auto-suivi utilisent un format XML ouvert pour transférer des données de suivi. La prise en charge de suivi pourrait donc être ajoutée aux plates-formes non -.net
     5. La performance de EF V4 est très bonne, car un travail approfondi a été effectué sur le générateur de requêtes
        • Voir le Entrée de blog Ado.net sur le sujet
          6. EF fournit des outils de conception visuels extrêmement riches, et permet une personnalisation étendue de la génération de code via la personnalisation Modèles et flux de travail T4
          7. EF v4 introduit de nombreuses interfaces, y compris le iObjectSet et Idbset interfaces, qui améliorent considérablement la testabilité de votre unité de vos contextes personnalisés
          8. EF V4 fait partie intégrante de .NET 4 et un composant central de toutes les initiatives de données courantes et futures de Microsofts. Dans le cadre de .net, sa documentation est assez vaste: MSDN, Blog eFDesign , blog Ado.net , dizaines de. Les sites et les blogs nets et de programmation fournissent une quantité énorme de documentation et de support de la plate-forme.

Un autre vote pour EF ici.

• Testable très facilement unitaire. Vous pouvez écrire vos propres entités de domaine et les faire être raisonnablement exemptes de sensibilisation à la persistance en utilisant Approche POCO . Vous pouvez ensuite vous moquer de l'interface de base de données et tester la logique de l'application sans base de données réelle.

• prend en charge Linq afin que si vous écrivez correctement votre LINQ, il ne fera que traduire une seule instruction SQL étant envoyée sur le serveur.

J'utilise un produit appelé LightSpeed ​​, ça fonctionne très bien Et s'intègre de manière transparente dans Visual Studio 2010 et 2008. Je l'utilise avec SQLite, mais elle prend en charge de nombreux SGDBR. Il possède également une très belle fonctionnalité qui vous permet de créer des objets POCO pouvant être utilisés avec WCF, excellent économiseur de temps! Au début, j'utilisais l'édition Express Free, mais bientôt mis à niveau.

LightSpeed ​​est la meilleure modélisation de domaine de domaine haute performance et de mapping O / R disponible. Première classe LINQ Support, Visual Studio 2008 et 2010 Intégration designer et notre célèbre cadre de base haute performance signifie que vous pouvez créer des modèles riches et axés sur le domaine plus rapidement que jamais auparavant.

ayant travaillé avec ce qui suit:

• NHibernate

• llblgen

• cadre d'entité

• linq à sql

• dataObject.net

• openAccess

• datables

  Je peux très certainement dire que les datables sont supérieurs ... non je plaisante. Tous ont leurs forces et leurs faiblesses.

  Principalement, j'ai constaté que ces forces et ses fekanesses sont associées au type général d'ormes, qui tombe dans les deux catégories suivantes

  • poids lourd

    • LLBLGEN, OpenAccess, Entity Framework (Pre 4.0), DataObjects tombe tous dans cette catégorie. Les orateurs de poids lourds ont généralement des entités et des collections qui héritent d'une classe de base spécifique à l'orj (ie. Entitébase). Ces orateurs offrent souvent des fonctions de prise en charge du temps de conception riche, de génération de code et de fonctionnalités d'exécution approfondies (telles que le suivi de l'état, le suivi des transactions, la maintenance d'association, etc.).

    • Le développement plus facile, le développement plus rapide d'Upfront exploitant l'API intégré pour interagir avec des entités elles-mêmes au moment de l'exécution (c.-à-d. de llblgen entity.fields ["myfield"]. Ischanged ou entité.Indew ou entité.fields [ "Myfield"]. DBValue

    • Le con: lourdité et dépendances. Avec ces ormes, vos objets professionnels sont maintenant liés directement dans l'API ORM. Et si vous voulez changer d'une autre orm? Et ce qui permet aux développeurs juniors d'abuser des fonctionnalités avancées de l'API ORM à résoudre un problème simple avec une solution complexe (j'ai vu cela une tonne)? L'utilisation de la mémoire est également un gros problème avec ces ormes. Une collection de plus de 5 000 entités et plus peut facilement prendre 100 Mo de RAM avec certains des orateurs ci-dessus. La sérialisation est un autre problème. Avec la lourdeur des objets, la sérialisation peut être très lente ... et cela ne fonctionnera probablement pas correctement désériorialiser de l'autre côté du fil (WCF ou .NET Remoting, etc.). Les associations risquent de ne pas être ré-associées correctement ou certains champs peuvent ne pas être préservés. Plusieurs des ormes ci-dessus ont construit des mécanismes de sérialisation pour améliorer le support et la vitesse ... mais aucun que j'ai vu offrir une prise en charge complète pour différents formats (c'est-à-dire que vous obtenez un support de sérialisation binaire, mais pas JSON ou XML).

    • poids léger

      • linq à SQL, cadre d'entité POCO, NHibernate (sorte de) tomber dans cette cateogry. Les ormes légers utilisent généralement des POCOS que vous pouvez concevoir vous-même dans un fichier dans VS (bien sûr, vous pouvez utiliser un modèle T4 ou un générateur de code).

      • Le pro: léger. Le garde simple. ORM Agnostic Business Objects.

      • Le con: moins de fonctionnalités, telles que la maintenance graphique d'entité, le suivi de l'état, etc.

        Quel que soit le choix que vous choisissez, ma préférence personnelle consiste à coller à Linq, et à la syntaxe de récupération indépendante de l'orme (pas la propre API de l'ORM pour la récupération, s'il en a une).

        En ce qui concerne les spécifiques mentionnés, voici mes brèves pensées: - NHibernate: Derrière The Times Tech Sage. Beaucoup de maintenance de fichiers de mappage XML (bien que le NHibernate fluide atténue cela).

        • llblgen: la plupart des ormes matures que j'ai travaillé. Facile de démarrer un nouveau projet et d'aller aller. Meilleur designer. Très lourd poids. Riche API très puissante. Meilleure vitesse que j'ai rencontrée. Parce que ce n'est pas le nouveau gamin sur le bloc, certaines des fonctionnalités les plus récentes exploitant de nouvelles technologies ne sont pas implémentées aussi bien qu'elles devraient être (spécifiquement).

        • Cadre d'entité: La classe POCO in 4.0 semble prometteuse. 3.5 n'a pas cela et je ne le considérerais même pas. Même en 4.0, ne dispose pas d'un excellent support Linq et génère une pauvre SQL (peut faire des centaines de requêtes de DB pour une seule requête LINQ). Le soutien des concepteurs est faible en ce qui concerne les projets plus importants.

        • linq à SQL: Super support Linq (meilleur que tout autre sauf dataObject.net). Prise en charge de la persistance médiocre (sauvegarde / mise à jour). Très léger (POCO). Le support design est pauvre tout autour (sans rafraîchissement de dB). Mauvaise performance sur les requêtes de Linq avancées (peut faire des centaines de requêtes de DB)

        • dataObjectS.net: vraiment grand support et performances de Linq. Offre la chose la plus proche que j'ai vue à Poco dans un orme lourd. Technologie vraiment nouvelle, puissante et prometteuse. Très flexible.

        • OpenAccess: Je n'ai pas travaillé avec elle une tonne, mais cela me rappelle un peu de Llblgen, mais pas comme une caractéristique riche ou mature.

        • Datables: Aucun commentaire

Après avoir utilisé OpenAccess sur plusieurs projets, je dois dire qu'il répond à tous les critères ci-dessus. Un système que j'ai travaillé était basé sur des services de la WCF parlant à plusieurs types de clients (Smart, Web, d'autres services de la WCF, etc.) via une architecture en couches Les services WCF utilisés ouvertes comme mécanisme de persistance. J'imagine particulièrement la mise à l'échelle que OpenAccess effectue .. Le cache de niveau 2 intelligent 2 (cache L2) fait un travail parfait et il est de cause distribuable. En fait, je n'appellerais pas un poids lourd de l'oa ... vous n'héritez même pas d'une classe de base. Il s'agit également d'un grand avantage qu'il existe des outils pour effectuer les tâches de développement quotidiennes (créez un nouveau schéma de DB, des schémas de fusion, etc.) intégré à Visual Studio.

À propos de EF4 ... Veuillez ne pas l'utiliser dans un grand projet, avec de nombreuses tables et beaucoup de données et de nombreux utilisateurs. J'ai fait cette erreur et je cherche maintenant un remplaçant.

Génération de la requête Bad 1, en particulier dans les grandes hiérarchies tpt. Préparez-vous pour une requête de 5000 lignes pour une hiérarchie de 15 tables!

2-extrêmement lent designer lorsque le nombre de tables grandit. 45 secondes juste pour effondrer / développer une entité dans un modèle avec 240 entités.

Problème 3 grave avec X-à-de nombreuses relations. Supposons que vous ayez commandez et client . Chaque commande a un client et chaque client a de nombreuses commandes. Il existe une propriété, nommée commandes dans Classement CLASSE qui sera peuplé sans que vous n'ayez jamais besoin de ces données. Cela signifiait, dans notre système, que des collections jusqu'à 1800000 entités soient extraites sans raison réelle. Lorsque cela se produit à l'intérieur d'une transaction avec un niveau d'isolation d'instantané ... qui apporte tout le système à l'échec. Il n'y a pas de solution réelle à ce problème, une personne qui n'a pas d'inconvénients sérieux. Il suffit de lire la documentation de DataObjectS.NET et voyez comment ils ont pris ce problème. J'ai trouvé que payer 200 ou 500 euros n'est rien comparé à ce que vous obtenez. Je peux même obtenir la version avec code source.

Si je ne peux pas intégrer mon système avec do.net, je vais chercher un autre, mais cette chose ef, elle doit aller!