août
2009
Comme il m’a fallu répondre, en l’espace de deux semaines, en ligne ou IRL, 5 fois a des questions gravitant autour des ORM, je me suis dit que ca ferait un bon sujet de post.
Sur ce point, mon avis personnel est le suivant : un ORM bien maitrisé génère des requêtes SQL qui sont en général plus stables, plus sécurisées et aussi performantes que des requêtes SQL écrites « en dur » dans le code.
Plus stables, parce que du coup, on évite, dans de nombreux cas, les erreurs de mapping entre le nom des champs de la base et le code (ou, du moins, on les détecte plus simplement). De plus, contrairement a une couche d’accès aux données ou un ORM « maison », utilise sur une poignée de projets, la plupart des ORMS disponible en .NET ont été utilisés sur un nombre très large de projets, les bugs corrigés et les cas limites atteints et documentes
Plus sécurisées, car, en général, ces frameworks utilisent des requêtes paramétrées, ce qui en soit est une sacrée évolution par rapport a la pratique « moyenne », ouvrent et ferment leur connections de façon respectueuse et gèrent les transactions simplement.
…et aussi plus performantes (ce qui est un point d’accrochage avec a peu prés tous les DBA)….a condition de rester conscient qu’on utilise une base de données derrière (sinon, bonjour les locks, les problèmes de Select N+1 et compagnie).
L’argument avancé en général par les opposants aux ORM est qu’un ORM mal utilisé peut faire crasher la base de données, ou plus généralement amoindrir les performances du serveur. Ce point est 100% valide…aussi valide que de dire qu’écrire des requêtes de jointures sur 5 tables en faisant des Select * détériore les performances.
Un ORM permets de réduire le cout, pour l’équipe projet, des requêtes SQL « simples », tout en faisant appel, dans les cas limites, a des moyens de contournement, comme l’appel aux procédures stockées, ce n’est pas une baguette magique qui va permettre d’ignorer la réalité de l’existence d’une base de données, qui est une ressource qu’il faut cajoler et traiter avec le respect du a un Mammouth de 15 tonnes (ou 85 Go), et pas comme la cinquième roue du carrosse.
Sinon, préparez vous au pire :
En résumé, si vous vous posez la question « faut-il utiliser un ORM », mon avis est (au risque de me fâcher avec les DBAs) définitivement oui, a la condition de ne pas débrancher son cerveau avant usage, et d’être prêt a investir du temps pour que l’ensemble de l’équipe projet soit au courant des bonnes pratiques d’accès aux données…
..mais bien entendu, ce sont des pré-requis pour toute manipulation impliquant une base de données. alors je ne suis pas inquiet
PS: amis DBA, ceci n’est pas un troll…si tel était le cas, j’aurais posté dans la rubrique SQL, avec un titre provocateur
7 Commentaires + Ajouter un commentaire
Articles récents
Archives
- janvier 2014
- septembre 2013
- août 2013
- mai 2013
- avril 2013
- janvier 2013
- août 2012
- juin 2012
- mai 2012
- avril 2012
- mars 2012
- novembre 2011
- septembre 2011
- août 2011
- juillet 2011
- juin 2011
- mai 2011
- avril 2011
- février 2011
- janvier 2011
- novembre 2010
- octobre 2010
- septembre 2010
- août 2010
- juillet 2010
- juin 2010
- mai 2010
- avril 2010
- mars 2010
- février 2010
- janvier 2010
- décembre 2009
- novembre 2009
- octobre 2009
- septembre 2009
- août 2009
- juillet 2009
- juin 2009
- mai 2009
- avril 2009
- mars 2009
- février 2009
- janvier 2009
Bonjour,
Je vous conseille de jeter un coup d’oeil au produit CodeFluent de la société SoftFluent: http://www.codefluent.com.
Attention, la dimension ORM est incorporée dans le modèle de persistance mais cela représente qu’une partie des fonctionnalités du produit.
Pour avoir une vue d’ensemble rapide du produit voici un article intéressant:
http://www.codefluent.com/article/developper-des-applications-net-architecturees-en-composants.aspx
Bonne journée,
Perso, sur les huits derniers mois, aprés deux ou trois spikes, tous les nouveaux projets (hors projets Sharepoint) ont été faits avec un ORM…et le gain de prod à littéralement écrasé le cout de l’apprentissage (équipe de 5 personnes, taille du projet moyen dans les 3 mois-homme).
L’un dans l’autre, un ORM est comme tout autre outil, que ce soit LINQ, ADO.NET ou le framework truc-machin qui est ajouté dans un projet, il y’à une phase d’apprentissage, mais après, ce n’est que du bonheur.
Quand on contournement de l’ORM, pour le moment, le seul contournement qu’on à vu, ca a été d’appeler directement une requete, sous la forme :
var objets= new InlineQuery()
.ExecuteAsCollection(maGrosseRequeteGeneree, param1, param2, …, paramN);
Ce qui génère une requête paramétrée toute propre, a ou, avec une DAL « classique3, et dans les circonstances ou ca s’est pasé, on se serait retrouvés avec une verrue à base de SqlCommand et de concaténation de chaine
Ok un ORM bien maitrisé permet de faire des bon logiciels, stables et performants tout en gagnant du temps en productivité. Mais le temps de bien choisir et maitriser le bon ORM n’est quand même pas négligeable.
Sur un petit projet on va passer plus de temps à choisir et apprendre à se servir d’un ORM, sur un trop gros projet on va se retrouver avec une partie non négligeable de l’applis qui contournera l’ORM pour diverses raisons…
Alors ok si on est une SSII qui fait régulièrement des applis de gestion de moyenne échelle, là ça vaut le coup de prendre le temps de faire un choix d’ORM et de former massivement son équipe. Mais pour le reste, les ORM ne m’ont pas encore convaincu
bah avec des ORM qui supportent LINQ, ca donne (pris depuis les tests de subsonic 3) :
var result = from p in _db.Products
join c in _db.Categories on p.CategoryID equals c.CategoryID
where p.CategoryID == categoryID
select p;
Je ne suis pas un expert dans le domaine mais j’ai l’impression que je perd plus de temps a créer des jointures avec un ORM plutôt que d’écrire directement ma requêtes…
Bon je n’ai jamais testé d’ORM .NET
Je m’appercois qu’ « article complet » est ajoute automatiquement, autant pour moi…..
« Article complet » => ne manque-t-il pas une (grosse?) partie de l’article?