Problème création modèle de classe + Oracle datasource

**mohe27** · 14/08/2010, 16h56

Salut les amis,

voilà je suis entrain de développer une application utilisant un projet MVC2 couplé avec une base de donnée Oracle, le souci que je rencontre est le suivant:
quand j'essaye de créer un modèle de classe (voir le lien ci-dessous au niveau de la Figure3) lors du choix de la source de données, je mets "nouvelle connexion" et là parmis les choix affichés il n'y a que ceux de "Sql server" celui de Oracle n'existe pas.

http://dotnet.developpez.com/mvc/mvc-entity-framework/

pourtant Oracle data provider pour .net est installé et la référence vers Oracle.DataAccess Version=10.2.0.100 (j'utilise Oracle 10g), est appliquée.

le test de connexion classique vers ma base Oracle fonctionne parfaitement seulement il n'est pas disponible quand j'essaye de créer un modèle de classe.

est-ce qu'il y a un composant qui manque et que je dois installer ou bien une autre référence à rajouter peut-être? car je suis bloqué là

j'utilise MVS 2008 SP1 avec MVC 2.0

merci pour votre aide

**tomlev** · 15/08/2010, 02h27

Le provider Oracle officiel n'est pas compatible avec Entity Framework. Le seul provider EF fourni avec le framework est celui pour SQL Server.

Il existe des providers Oracle qui supportent EF (chez Devart par exemple), mais c'est payant...

EDIT: apparemment Oracle a enfin commencé à se bouger le c** à ce sujet...
http://www.oracle.com/technetwork/to...sod-130214.pdf

Mais c'est pas pour tout de suite, ils parlent d'une beta pour fin 2010, et d'une version finale en 2011

**cinemania** · 15/08/2010, 11h40

effectivement il n'existe à ce jour que 2 connecteurs compatibles EF pour Oracle, et ils sont payants, et encore un des 2 est "moyennement" compatible, en gros l'interface intégré de VS tu t'assoies dessus...

il te reste donc le connecteur Devart (Outils|Gestionnaire d'Extensions sous VS2010 pour le chercher et l'installer) qui s'intègre parfaitement à Visual studio en plus de fournir les connecteurs compatibles EF.

De toute façon... si tu part sur Oracle c'est que tu es prêt à payer plein pot pour pas grand chose, c'est donc pas un connecteur payant qui va te faire peur

enfin bon je dis ça je dis rien.

**mohe27** · 15/08/2010, 11h51

Salut les amis,

je vous remercie tous les deux pour cette information, et je trouve ça dommage qu'Oracle n'ait pas pensé à créer un connecteur pareil comme c'était le cas pour son ODAC pour .net, il faudra alors attendre sinon voir avec le boss s'il voudra se procurer celui de chez Devart, sinon passer sous Sql server.

merci les amis

**tomlev** · 15/08/2010, 13h16

Envoyé par mohe27

je trouve ça dommage qu'Oracle n'ait pas pensé à créer un connecteur pareil comme c'était le cas pour son ODAC pour .net

Ben c'est pas qu'ils y ont "pas pensé" à mon avis, c'était plutôt un choix politique... Quoiqu'ils en disent dans leur communiqué, Oracle a toujours été assez réticent à fournir des outils pour .NET. Y a qu'à voir le provider ODP.NET actuel, il s'intègre relativement mal à cause d'une interprétation très personnelle du modèle ADO.NET 2... Notamment la gestion des transactions, ou le fait que les paramètres soient bindés par position et pas par nom par défaut, c'est super galère si tu codes en faisant abstraction du SGBD

Envoyé par mohe27

sinon passer sous Sql server.

Ben si j'ai le choix, je préfèrerai toujours utiliser SQL Server qu'Oracle, du moins pour des développement en .NET. L'intégration à Visual Studio est bien meilleure

**mohe27** · 15/08/2010, 13h40

Dis moi tomlev,

est-ce que je peux utiliser un Dataset comme modèle? je viens de faire un petit essai le drag and drop des tables se fait sans souci mais qu'en est-il des appels des differents champs de ses tables ??

merci à toi

**cinemania** · 15/08/2010, 13h57

Le choix politique d'Oracle a empiré avec le rachat de Sun, du fait que Oracle est devenu propriétaire de Java ...

La seule raison qui fait qu'ils se décident enfin à bouger est due uniquement au fait que la BDD Oracle soit en net recule face à SQL Server ces derniers temps, et qu'ils ne doivent leur survie, en terme de "succès" qu'aux infrastructures de BDD sous UNIX, sous Windows... la donne a bien changé.

Offrir des outils pour DOTNET n'est donc pas une volonté politique, mais une nécessité, s'ils ne veulent pas perdre définitivement le marché, et voir toutes les BDD à haute volumétrie passer sous Windows Server & SQL Server, car de plus en plus les applicatifs commencent à se développer en DotNet pour l'utilisation sous Windows.

**mohe27** · 15/08/2010, 14h21

merci cinemania,

j'avoue que Sql server est un produit formidable du point de vue puissance et outils dont ils dispose pour different besoins en autre la Business intelligence avec sa partie reporting assez etonnante. déjà sa version 2005 était un rebond considerable mais là avec sa version 2008 je doit dire que Microsoft prend une nette avancée en ce créneau.

**tomlev** · 15/08/2010, 15h27

Envoyé par mohe27

est-ce que je peux utiliser un Dataset comme modèle ?

Tu peux, mais perso je suis pas fan... d'abord, il faut bien comprendre que ça n'a pas grand chose à voir avec un ORM comme Entity Framework. Tu charges les données dans le DataSet avec des DataAdapters, tu travailles dessus, et quand tu as fini tu mets à jour la base avec les DataAdapters. C'est nettement moins pratique... En plus tu n'as pas de contrôle sur les noms des classes et méthodes générées, et les noms par défaut sont assez peu pratiques.

En fait, le modèle généré est beaucoup trop lié au mode de fonctionnement du DataSet pour pouvoir en faire abstraction facilement, alors qu'avec EF tu peux déclarer toi-même tes classes POCO et les mapper au modèle.

D'autre part, EF permet de convertir directement des requêtes Linq en requêtes SQL, ce qui n'est pas possible avec les datasets...

Bref, si tu veux vraiment utiliser Oracle ET que tu as besoin d'un ORM, oriente toi plutôt vers NHibernate (mais c'est assez imbitable), ou alors utilise le provider EF de Devart...

**mohe27** · 15/08/2010, 15h51

ok tomlev,

ça parrait être très fastidieuse comme approche au lieu de s'amuser en mettant du code là on va vite être dégouté

je vais voir côté NHibernate sinon passer carrement à Sql server, je pense que ça va me faire gagner un bon bout de temps.

merci

**tomlev** · 15/08/2010, 16h02

Envoyé par mohe27

sinon passer carrement à Sql server, je pense que ça va me faire gagner un bon bout de temps.

Si tu n'as pas de contraintes sur le choix du SGBD, je pense que c'est la meilleure option

**cinemania** · 15/08/2010, 17h50

surtout si tu annonce à ton employeur que les licences sql server sont largement moins chères que Oracle

et ça ne mange pas de pain, mais pour microsoft 1 processeur = 1 processeur, pour Oracle 1 processeur = 1 coeur... donc aux jours d'aujourd'hui pour faire tourner Oracle DB sur une machine décente, faut donc investir dans 4 licences logicielles Oracle

**mohe27** · 16/08/2010, 10h52

tomlev:
Si tu n'as pas de contraintes sur le choix du SGBD, je pense que c'est la meilleure option

Il n'y a pas de problème pour passer sur le SGBD de Microsoft vue qu'au niveau de l'entreprise nous en disposons déjà, c'est simplement que certaines données utilisées au niveau de cette application proviennent d'une DB Oracle c'est pour ça que ça me bloque.

cinemania:
pour microsoft 1 processeur = 1 processeur, pour Oracle 1 processeur = 1 coeur... donc aux jours d'aujourd'hui pour faire tourner Oracle DB sur une machine décente, faut donc investir dans 4 licences logicielles Oracle

est-ce que tu peux me donner plus de détails concernant la problématique des coeurs au lieu des processeurs ??

comment ça se calcule pour Oracle et qu'elle est la difference entre cette politique et celle de microsoft ??

merci à vous deux

**tomlev** · 16/08/2010, 10h56

Envoyé par mohe27

comment ça se calcule pour Oracle et qu'elle est la difference entre cette politique et celle de microsoft ??

C'est juste que tu dois payer une licence par coeur pour Oracle, et une licence par processeur pour SQL Server (peu importe le nombre de coeurs)

**mohe27** · 16/08/2010, 11h01

ahh ok il s'agit des processuers multicoeurs alors, je comprends.

mais côté performance qu'elle est le SGDB qui tire le meilleur parti des nouveaux processeurs multicoeurs?

et doit-on utiliser des UC 64bits pour un rendement plus conséquent ??

**cinemania** · 16/08/2010, 11h14

ca ne tiens pas tant à la problématique des processeurs multicore mais du SGBD lui même.

Sur les bases petites et moyenne historiquement et à plus forte raison maintenant SQL Server a toujours été (quelque soit sa version) nettement plus performant qu'Oracle.
Une des raisons est que SQL Server utilise une technologie que seule Sybase utilise à part Microsoft qui consiste à compiler ton code SQL en algèbre relationnelle, puis a effectuer une optimisation sur l'ordre des opérations atomiques, ce qui peut impacter les performances du simple au triple, même pour une requête simple, ensuite il sort donc le plan d'exécution et l'exécute.

Avant SQL Server 2005, dès que la volumétrie d'une base de façon générale dépassait les 200Go, on préférais Oracle, car dans ce cas précis, il était plus rapide, et donnait de meilleurs résultats sur la gestion de la base, sans parler des possibilités comme le clustering et compagnie, nettement mieux gérées.

Depuis SQL Server 2005, les améliorations sensibles apportées au noyau de SQL Server, notamment sur le moteur de requêtes, et sur les options avancées pour la montée en charge, comme le clustering et compagnie, ont fortement augmentées ses capacités de traitement.
Du coup les avantages à utiliser Oracle ont commencé à s'étioler, même sur des bases de plus de 1To, en obtenant des performances équivalentes (parfois un peu plus rapide, parfois un peu moins, mais dans la même moyenne)

Depuis l'avènement de SQL server 2008 et tout particulièrement le R2, l'équilibre est totalement rompu, car désormais il y a une très nette différence entre SQL Server et Oracle, et il n'y a désormais plus aucun intérêt à utiliser Oracle si ce n'est celui d'être un pigeon qui paye plus cher, pour moins bien.
En effet, les performances de SQL Server 2008 sur Oracle sont assez importantes, même sur des volumétries passant les 1To.

C'est pourquoi je vois pas mal de migration, parmi les clients de la société où je travail, ou les prospects et relations que l'on a dans d'autres sociétés.
Ajouté à cela la politique de prix de Microsoft..

Il ne faut pas oublier que désormais la grande majorité des processeurs Xeon utilisés en infrastructure serveurs, sont à minima des Quad Core... donc ... sous Oracle tu banque direct avec la plus petite des configurations.

Pour ce qui est de l'infrastructure 64bits il est indaignable que c'est devenu quasi-indispensable sous des plateformes serveur.
Seule les infrastructures 64 bits permettent de tirer pleinement partie des possibilités offertes par le hardware.
Inutile d'avoir un mainframe à 128Go de RAM en 32 bits, même si les versions serveurs sont capable de gérer cela, elles le feront toujours moins bien qu'une édition en 64 bits.

**mohe27** · 16/08/2010, 12h04

cinemania je te salue et remercie pour toutes ces precisions

pour un DBA, il y a deux formations importantes concernant Sql Server 2008 à savoir:

6231: Maintaining a Microsoft SQL Server 2008 Database (5j)
6232: Implementing a Microsoft SQL Server 2008 Database (5j)

je projette de les faire, si tout est ok avec mon employeur pour me les payer

**cinemania** · 16/08/2010, 15h10

Envoyé par mohe27

6231: Maintaining a Microsoft SQL Server 2008 Database (5j)
6232: Implementing a Microsoft SQL Server 2008 Database (5j)

je projette de les faire, si tout est ok avec mon employeur pour me les payer

Si tel est ton souhait, je ne peux que t'encourager à les faire surtout si ton employeur est d'accord pour les financer.
Tu y verras notamment comment "optimiser" une base et les requêtes sur celle-ci pour améliorer les temps d'accès, et de réponses, et surtout les erreurs à ne pas faire, que beaucoup malheureusement font.
(Avoir un bon SGBR ne fait pas tout non plus)