Meilleur outil ORM pour Oracle avec 4000 tables

Question

Je suis à la recherche du meilleur outil ORM .Net qui fonctionnerait avec Oracle et SQL Server 2005. Nous avons une base de données Oracle avec environ 4000 tables. J'ai essayé TierDeveloper et Codesmith et ils ne répondent pas lorsque j'essaie de mapper des objets avec ma base de données Oracle. Quel sera le meilleur outil ORM pour travailler avec une grande base de données Oracle ?

Answer 1

Je regarderais sérieusement ibatis (pour Java et .Net). Je dis cela pour quelques raisons :

Tout d'abord, je pense que les ORM comme NHibernate, qui tentent vraiment d'abstraire la base de données, peuvent être contre-productifs, notamment lorsqu'il s'agit de bases de données "héritées". Le terme "hérité" ne signifie pas ce que l'on croit. Des outils comme Hibernate et JPA (Java) considèrent à peu près tout ce qui n'est pas fait de la "bonne" manière comme étant hérité, ce qui peut inclure l'utilisation de clés composites (sérieusement, j'ai lu un livre JPA qui qualifiait les clés composites de "héritées").

Ibatis, quant à lui, vous offre la plupart des fonctionnalités d'un ORM (et certaines choses qu'Hibernate, par exemple, ne peut pas faire comme la fonctionnalité groupBy) tout en vous laissant la possibilité d'écrire du SQL brut. J'imagine qu'avec une base de données aussi vaste, vous allez rencontrer des décisions de modélisation douteuses qui seront difficiles, voire impossibles, à mapper dans de nombreux ORM. En écrivant du SQL direct, vous pouvez gérer ces situations dans ibatis par définition.

Les ORM qui ne sont pas spécifiques à un fournisseur sont également le plus souvent limités en termes de langage de requête. Si toutes les bases de données ne le peuvent pas, alors vous ne pouvez pas le faire nulle part. Oracle possède l'un des dialectes SQL les plus sophistiqués. Vous devriez l'utiliser. Des choses comme CONNECT PRIOR n'existent pas dans de nombreux autres dialectes SQL (et ne sont donc pas modélisées de manière performante dans des ORM abstraits).

J'ai écrit davantage sur ce sujet dans Utiliser un ORM ou du SQL brut ?

Le fait que vous soyez limité par la conception existante renforce encore l'idée de rester le plus proche possible du SQL.

Answer 2

Si vous n'avez pas de modèle d'objet, je réfléchirais à deux fois avant d'utiliser un ORM. Je pense que c'est une erreur d'avoir une correspondance 1:1 entre les tables et les colonnes, les objets et les attributs. Si les objets sont juste des structs, sans comportement ou encapsulation de règles, quel est l'intérêt?

Dans ce cas, je préférerais une autre approche : iBatis, JDBC direct, les procédures stockées ou quelque chose d'autre qui vous permettrait de ajuster le SQL au lieu de dépendre des éléments générés par l'ORM.

MISE À JOUR : Oracle possède TopLink. Cela me ferait supposer qu'ils l'ont "optimisé" pour fonctionner bien avec leur base de données :

http://www.oracle.com/technetwork/middleware/toplink/overview/index.html

Mais la vérité est qu'il n'y a rien que l'outil ORM puisse faire si votre schéma est mal fait (par exemple, mauvais indexage, JOINTURES excessives, mise en cache, etc.). La base de données sous-jacente aura une influence importante sur vos performances perçues.

Answer 3

Utilisez XAF, le produit de DevExpress, pour plus de détails consultez http://www.devexpress.com

Answer 4

Essayez EntityORM: http://entityorm.uuuq.com

EntityORM est une bibliothèque de mappage objet-relationnel entièrement typée pour .NET 2.0.

La principale force d'EntityORM est la facilité d'utilisation. La plupart des bibliothèques ORM nécessitent encore beaucoup de conversions de types et d'autres tâches fastidieuses à écrire, EntityORM est conçu pour soulager le programmeur de ces tâches fastidieuses et sujettes aux erreurs, le rendant très intuitif à utiliser.

Les principales fonctionnalités sont :

* Indépendant de la base de données
* Facilité pour créer de nouveaux pilotes indépendants du framework principal d'EntityORM (actuellement, il existe des pilotes pour Sql Server, Sql CE, MySql, Oracle, PostgreSQL et Access)
* Marquage automatique des entités modifiées (optionnel)
* Chargement paresseux automatique (optionnel)
* Transactions automatiques (transaction manuelle optionnelle par exemple pour un commit en deux phases)
* Facilité de mapping pour une base de données existante avec un effort minimal
* Tous les types relationnels sont pris en charge (Un-à-Un, Un-à-Plusieurs, Plusieurs-à-Un, Plusieurs-à-Plusieurs)
* Cadre d'événements flexible
* Conditions pour filtrer les données à charger dans les entités
* Capacité de mapper différents noms de tables ou de champs
* Valeurs par défaut
* Validation des règles
* Numérotation automatique
* Guid
* Liste générique pour gérer plusieurs entités masquées des entités supprimées
* Les entités typées sont chargées de manière paresseuse avec mise en cache, réduisant considérablement le besoin de réflexion
* Vues d'entités pour charger plus rapidement des données en lecture seule à partir d'une ou de plusieurs tables dans une entité plate unique
* Conditions de jointure pour joindre plusieurs tables dans une seule vue d'entité
* Liste générique pour gérer plusieurs vues d'entités
* Distinct, groupes automatiques et fonctions d'agrégation (compter, somme, plus grand, moyenne, plus petit) pris en charge dans les vues d'entité