Salut ,
Comme le titre l'indique, est-ce que j'utilise un orm pour mon application j'ai entendu NHibernate il est bien ? ou vous me conseillez de faire mon propre orm ?
et merci
Version imprimable
Salut ,
Comme le titre l'indique, est-ce que j'utilise un orm pour mon application j'ai entendu NHibernate il est bien ? ou vous me conseillez de faire mon propre orm ?
et merci
Utilise LinqToSQL plus facile et plus efficace
(il me semblait que linqtosql était mort né)
les orms font gagner du temps en développement (bien que dans certains cas la flexibilité s'obtient à coup de code moyennement simple)
par contre en théorie ils ne peuvent être que moins performant qu'un bon développeur sql
après si tu n'y connais pas grand chose en sql (c'est presque aussi vaste que c#) ca ne sera pas forcément pire ^^
mais au final tout dépend de l'appli, pour une appli de consultation avec 30 forms et 50 tables ca peut convenir
si c'est pour une appli temps réel avec des Go de données il vaut mieux prendre le temps d'écrire les requetes soit même
sinon rien n'empêche de mixer, à savoir utiliser un orm et écrire certaines requetes sur des points identifiés comme lent avec l'orm
nhibernate a été dans les premier, microsoft a aussi fait un orm bien intégré à visual studio, Entity Framework (les versions récentes sont censées être mieux que la 1ère version de 2008)
(pas sur qu'il soit dispo sur la version express, à vérifier le cas échéant avec clic droit ajouter un entity data model)
au niveau fonctionnement ca ressemble à
tu coches les tables et ca écrit le code tout seul, classes pour contenir, requete de select/insert/update/delete avec les méthodes qui vont avec
pour les jointures 1-n ca peut faire une propriété as collection d'une autre classe/table
enfin il y a pas mal de choses à apprendre dessus, mais une fois qu'on maitrise c'est clair que ca enlève une partie du code
ca ne dispense pas par contre de mettre des indexes dans les tables
Tu as aussi Dapper qui est léger et simple d'utilisation.
Un membre a fait un article dessus :http://tlevesque.developpez.com/tuto...s-avec-dapper/
En 2008, notre équipe a créé son propre ORM après avoir été déçu du manque de flexibilité de nHibernate + SQL Server et des promesses non tenues de Linq2SQL. Nous avons réussi à grand coups de code élégant mais complexe. Surtout, le cout n'en valait pas la chandelle en rétrospective sachant aujourd'hui qu'Entity Framework allait devenir une option sérieuse.Citation:
Envoyé par yamisaaf
Le grand danger des ORMs est la notion fausse et archi-fausse qu'ils absouent le développeur de la responsabilité de connaitre les bases du design de base de données, notamment les règles de normalisation et la planification des indexes.
Les ORMs tendent à accélérer un projet en amont et le ralentir en aval. Au début, ça créé beaucoup de fonctionnalités mais alors que le projet nécessite plusieurs ajustement, l'ORM vient souvent alourdir le processus de refactoring.
Je ne prétends pas avoir la science infuse et j'utilise moi-même les ORM dans la plupart des cas mais il faut considérer ceci:
1 - Je créé TOUJOURS la base de données avant de la faire mapper dans Entity Framework. Le "code-first" peut créer des monstres.
2 - Je créé TOUJOURS une abstraction (DAL) entre EF et mon code. Je ne veux pas que mon code métier connaisse les entités générées par l'ORM. Ça ajoute de l'overhead au début mais ça sauve beaucoup de temps lorsqu'il y a du refactoring ou des changements majeurs.
3 - Je sépare mes bases de données en schémas afin de créer des mappings logiques plus petits. Grosso-modo, je ne veux pas de mappings de plus de 10 tables.
Donc:
Explorer Entity Framework, apprend comment abstraire la couche de données, apprend la normalisation et garde les choses simples.
Ok merci pour vos conseil , sinon si vous pouvez me donner des avis sur LinqToSql ? il est bien ?
Question intéressante tellement les choses ont évoluées depuis 10 ans.
Personnellement j'ai été confronté plusieurs fois à ce besoin d'ORM et j'ai toujours tenté les solutions intégrées fournies par MS (i.e. EF) :
- en 2008 : un existant important avec des classes et un schéma complexes (SQL Server 2005)
à l'époque j'avais tenté EF 1.0 mais il était "inutilisable" donc j'ai finalement utilisé LINQ to SQL qui a fait le job.
- en 2010 : pas d’existant mais des contraintes de temps et de maintenabilité et une base de données MySQL
je réessaye avec EF (version 4.0) : mieux mais encore overengineeré, au final j'utilise NHibernate qui est plug and play
- en 2013 : pas d’existant, pas de contraintes et base SQL Server 2012
EF 6.0 cette fois et là je retrouve l’effet plug-and-play de NHibernate, le workflow "code first" permet d'éviter l'usine à gaz.
Désormais je recommande plutôt EF, notamment pour son support intégral de LINQ et son intégration à VS qui est toujours rassurante pour certains clients.
Sache que LINQ2SQL est désormais obsolète, toutes ses fonctionnalités ont été intégrées à EF.
Quant au processus de design je ne peux que plussoyer Babyneedle et je me sens moins seul avec mon workflow exotique "code-first db-first" où je designe également indépendamment mon schéma relationnel et mon modèle OO de classes, avant de les lier via la tuyauterie de l'ORM. :)
De même il "faut" bien isoler le code de l'ORM, pour cela j'utilise le pattern repository.
Après utiliser un ORM ne vas pas nécessairement aider si tu as 1 table et 2 requêtes à faire, même s'il ne vas pas non plus complexifier : depuis l'introduction des DbContext et DbSet EF n'est plus une usine à gaz et s'utilise très simplement (du moins avec SQL Server).