Version imprimable
Bonjour,
Actuellement en discussion sur les choix techniques/technologiques d'un projet d'envergure à venir, je me demandais si des développeurs SQL ou des DBA avaient eu l'occasion de travailler sur un projet développé avec CodeFluent Entities, s'ils avaient un retour d'expérience sur les facilités ou difficultés qu'ils ont pu rencontrer.
En règle générale Frameworks et ORM génèrent un code très pauvre et rarement optimisé. SI c'est pour un projet d'envergure mieux vaut utiliser des procédures stockées et le concept de développement épais en BD.
À me lire : http://sqlpro.developpez.com/cours/b...s-epaisses.pdf
A +
Bonjour SQLPro,
Et merci pour ta réponse.
Effectivement j'ai pu lire cet article à plusieurs reprises, il fait partie de mes MUST HAVE. J'aimerais tellement pouvoir mettre en place les solutions évoquées dans ce dernier, malheureusement mon avis ne pèse pas lourd dans la balance, malgré ma fonction de DBA... Il existe un écart tellement important entre la vision des choses entre DBA et Développeur que c'est loin d'être facile.
A priori CodeFluent Entities aurait tendance à utiliser les procédures stockées mais jusqu'où...
J'ai pourtant réussi à convaincre (à force d'exemple certes...) les plus septique de mes collègues FAN du 'tout en code client rien dans la base'...
En autres le directeur technique et un 'expert' dotNet
Des batchs de plusieurs heures magnifiquement codé en LINQ TO ENTITIES pour importer 20000 clients...
Refait en deux heures de temps en SQL résultat : 50 seconde...
Bonjour Iberserk,
Je n'ai malheureusement pas la même expérience que vous (SQL Pro et toi) sur le sujet.
J'ai beau citer régulièrement vos exemples et vos retours d'expériences que je lis sur le forum ou sur vos articles, tant que c'est chez le voisin, on prend note mais sans y porter un grand intérêt.
Pareil :mouarf:Citation:
En autres le directeur technique et un 'expert' dotNet
Courage, ils plieront un jour ou l'autres :-) je vous le souhaiteCitation:
Envoyé par SQLDev
La remarque qui tue à leur livrer...
"Pourquoi croyez vous que tous les 2 ou 3 ans, un changement de technologie majeur se fait sur ce genre de framework/ORM ?"
On peut citer en 10 ans : ASP, LINQ, EntityFremework et maintenant le révolutionnaire CodeFluent... Bref, une stabilité du code excellente et rationnelle n'est pas ?
dans le même sens :
"Pourquoi croyez vous que depuis 30 ans, les SGBD Relationnels n'on pas subit de tels changements ?"
A +
Bonjour,
CodeFluent Entities n'est ni un framework (bien qu'il y ait du code dedans) ni un ORM (bien que forcément il y ait une jonction entre .NET et la base de données). C'est un générateur de code piloté par un modèle. Il a justement été conçu pour être le plus possible DBA-friendy (génération de tables, contraintes, vues, procédures stockées, pas de SQL dynamique) tout en reconnaissant l'intêret de l'orienté objet pour tout ce qui n'est pas base de données.
On peut trouver un article comparatif entre ce produit et les ORM (surtout Entity Framework mais les remarques sont à peu près les mêmes.
Je vous encourage à l'essayer (il est d'ailleurs complet et gratuit pour une utilisation non commerciale) plutôt que de le jeter à la poubelle à cause d'idées toutes faites :lol:
Bonjour,
Pour le moment, je suis surtout à la recherche de retours d'expériences. On ne trouve pas beaucoup de témoignages sur le sujet, malheureusement.
Je ne vois pas trop l'intérêt de comparer une tentative de nouvelle solution à une usine à gaz merdique.
Le seul test qui vaille, c'est de comparer CodeFluent Entities à un système "manuel" avec BDD épaisse.
Eventuellement, si c'est vraiment mieux que Entity Framework par exemple, on pourra l'inclure dans la comparaison.
Car si la BDD épaisse prend 1 seconde pour faire un traitement, CodeFluent en prends 2 et que Entity Framework en prend 10, alors on peut dire que CodeFluent est pas mal.
Mais si CodeFluent met 1, Entity Framework met 2, on se dit "chouette c'est deux fois plus rapide". Mais si un dev "manuel" avec BDD épaisse met 0,1, ben CodeFluent reste toujours autant pourri.
CodeFluent Entities est basé du coté .NET sur de l'ADO.NET standard, avec des IDbConnection, IDbCommand et des IDataReader (c'est multi base, pas uniquement SQL Server mais aussi Oracle, PostgreSQL ou MySQL). Du coté SQL server, c'est basé sur l'utilisation de procédures stockées, vues, etc. Il n'y a rien de dynamique, et le code généré est tout à fait lisible, pratiquement comme s'il était écrit à la main.
Il y a un comparatif avec d'autres technologies (y compris les ORM) ici http://blog.codefluententities.com/2...ce-comparison/
On trouve quelques retours ici (en Anglais): http://visualstudiogallery.msdn.micr...8-66E8C16AB410
Le bench me semble relativement... comment dire... nul (il ne reflète en rien un scénario réel)
En tout cas, ce que je remarque, c'est que ça reste deux fois plus lent qu'en utilisant SqlClient de base.
Au détail près qu'on ne sait pas si le SqlClient passe par des requêtes dynamiques mal écrites, une procédure écrite au petits oignons, ou un code généré récupéré d'un autre test.
De nombreux ORM ne savent même pas faire une simple jointure.
Alors si on compare d'un côté CodeFluent qui passe par une PS optimisée, et de l'autre côté un "select * from table1" puis ligne par ligne "select * from table2 where id = @id", si SqlClient reste plus rapide, alors CodeFluent est clairement à mettre à la poubelle.
Si les deux utilisent les mêmes objets, alors on peut éventuellement se dire "mouais, pourquoi pas", et encore... si dans un cas réel, ça reste deux fois plus lent... non merci.
C'est forcément plus lent qu'SQL Client de base vu que ça apporte quelques fonctions. Le but n'est pas de faire le plus rapide possible mais un compromis entre le coté pratique/rapide et performance, sans rien de dynamique. En programmant TDS en assembleur, je pense que je peux aller plus vite encore.
Bon, enfin, le mieux c'est de tester soi même, avec un scénario réel en effet. La question c'était "retour d'expérience", pas "j'ai pas essayé et je ne sais pas ce que c'est mais c'est sûrement de la merde" :)
Ben Linq par exemple, est plus rapide pour parcourir des objets en mémoire que du code en dur (surtout si ce dernier n'est pas optimisé).
Donc on pourrait tout à fait s'attendre, justement, à ce qu'une surcouche permette d'optimiser certains traitements.
Si ça ne le fait pas, ça ne sert, selon moi, pas à grand chose : l'accès aux données est souvent le gros goulot d'étranglement d'une application, alors pourquoi le ralentir ?
C'est complètement faux!!! et normal...Citation:
Ben Linq par exemple, est plus rapide pour parcourir des objets en mémoire que du code en dur
Amusez vous à faire des tests (déjà fait chez nous...)
Exemple: FirstOrDefault ou First ou ANY etc...
Remplacé avantageusement (jusqu'à deux fois plus rapide même sur des données simples...) par des classique for.
Si vous avez de meilleur perf avec LINQ vous pouvez remettre en cause votre code 'en dur'!.
Le seul intérêt que l'on pourrait trouver à un ORM est le gain de temps qu'il engendre lors de la création de la couche client d'accès aux données (DAL).Citation:
l'accès aux données est souvent le gros goulot d'étranglement d'une application, alors pourquoi le ralentir ?
Avec LINQ to SQL (dbml) ou ENTITIES (edmx) il suffit une fois la base créee (j'insiste sur ce point...) de drag & dropper une vue par exemple pour pouvoir requèter sur des objets correspondant à cette vue sans passer par la création manuelle d'un objet puis d'un fastidieux mappage entre le résultat d'une requête effectuée directement en ADO.NET (SqlCommand, DataReader...) et cet objet...
Dans mon équipe j'ai imposé 100% des requêtes autres que les SELECT en procédures stockées... et les requêtes complexes via des fonctions tables mappées...
Les données (listes de références bien souvent) mise en cache serveur(IIS) sont des requêtes directes sur des VUES SQL avec notification de cache personnalisé (celui de MICROSOFT intégré SqlCacheDependancy étant limité).
De ce que j'ai compris, CodeFluent génère la base de données à partir du modèle objet ainsi que les procédures stockées de mise à jour.
Après on peut toujours ajouter des index par-ci, par-là, mais la structure est gérée par CodeFluent.
D'où mon inquiétude, on imagine difficilement qu'un outil puisse faire le travail d'un DBA au niveau architecture de base de données. Ca peut peut-être fonctionner pour les applis qui gèrent des données relativement "simples" mais sur des projets importants j'ai peur que l'on se retrouve avec une architecture peu performante.
Salut à tous,Ah, euh, il faudrait nuancer un peu là...Citation:
Envoyé par iberserk
LINQ n'est pas les expressions lambda. Ensuite, je serai curieux de voir cela. Je suis d'accord si tu utilises des listes/collection simples, mais un FirstOrDefault sur une SortedList laisse la boucle for sur place ^^Citation:
Envoyé par iberserk
Comme d'habitude, il faut se servir des objets appropriés pour chaque usage.
A+
Salut Immobilis pour une fois c'est toi qui viens chez nous :ccool:
D'Accord avec toi, en l’occurrence tu triches ici puisque tu utilise une liste triée, ce qui n'est pas mon cas...Citation:
Comme d'habitude, il faut se servir des objets appropriés pour chaque usage.
As tu pris en compte le coût d'alimentation de ta liste triée (en l’occurrence le coût induit par le tri en lui même)?
Ton exemple reviens à utiliser un dictionnaire à peu de chose près...
Poh poh poh :D La "question" c'était une boucle for est-elle plus rapide qu'un FirstOrDefault ;)Citation:
Envoyé par iberserk
C'était pas l'objet du test, mais je veux bien le faire pour te faire plaisir. :)Citation:
Envoyé par iberserk
Tout à faitCitation:
Envoyé par iberserk
A+
Voilà qui est fait. Ci-dessous le nombre de ticks pour générer 10000 éléments uniques. En premier le dictionnaire, en deuxième une liste.Citation:
Envoyé par Immobilis
Le code:A+Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Bon, ben je mange mon chapeau! :oops:
J'ai retouché la boucle for qui m'a permis de dire hier que la SortedList était plus rapide. En fait, j'ai codé avec les pieds et la boucle était retardée par ma faute :aie: La dernière version indique bien que l'expression lambda sur la SortedList avec une clef de type valeur est moins rapide que la boucle "for". Bon, ce sont des ticks et pas des ms, mais tout de même :P
Moralité, accédez aux valeurs d'une SortedList directement par la clef...
Bon à savoir :ccool:
Prout:ccool:
Mais tout test reste bon à prendre...