|
Bas de page | |
---|---|
Auteur | Sujet : Quel ORM choisir ? |
![]() Publicité | Posté le 26-08-2008 à 13:55:17 ![]() ![]() |
MagicBuzz |
the big ben | Mais par contre linq question confort de programmation et le fait de gagner pas mal de temps sur la couche objet ca laisse reveur! |
haazheel | A voir aussi que NHibernate vient de passer en version 2.0, avec peut-être (j'ai pas regardé le changelog) des améliorations des perfs... --------------- Another .Net Blog |
m3z il faut toujours faire simple |
|
moi23372 |
--------------- quand un homme raisonne mal c'est qu'il n'a pas les données pour raisonner mieux (diderot) |
moi23372 |
--------------- quand un homme raisonne mal c'est qu'il n'a pas les données pour raisonner mieux (diderot) |
moi23372 |
--------------- quand un homme raisonne mal c'est qu'il n'a pas les données pour raisonner mieux (diderot) |
![]() Publicité | Posté le 27-08-2008 à 13:04:36 ![]() ![]() |
juflo | Bonjour
|
TotalRecall | Personne ici n'évoque Subsonic, pourtant depuis deux ans il commence à rencontrer une popularité certaine, bien qu'il ait ses inconvénients (pas de gestion propre du lazy loading sur les FK d'une table, langage de requêtage très loin d'égaler LINQ... Il y a aussi mygeneration qui vaut le détour parait il. Je n'évoque ici que les gratuits pas encore cités, après il y en a des tas d'autres (entity spaces, codesmith...) Personnellement aussi bien au boulot qu'à titre perso j'utilise LINQ, c'est le langage de requêtage (plus besoin de procstock ou d'écriture alambiquée pour les requêtes simples) qui fait toute sa force. Globalement on peut lui reprocher quelques défauts de design (le context qui sert de fourre tout par exemple) mais jusque alors je n'ai trouvé aucune limite restrictive. La gestion du lazy loading, aussi bien sur les champs que sur des tables (via "loadwith" ) est très pratique à utiliser par exemple. edit : tu ne précises pas si tu veux un ORM qui sert juste à "t'interfacer" avec ta base de façon élégante ou qui te prenne en charge dérrière tout un modele objet lourdingue comme l'entity framework que je n'ai pas évoqué. Message édité par TotalRecall le 30-12-2008 à 12:49:39 --------------- Topic .Net - C# @ Prog |
pot2yaourt | En fait, je recherche plutôt quelque chose de relativement simple à utiliser et s'il peut me générer les classes métiers ça serait pas mal.
--------------- On dit que les gens veulent du travail, mais c'est faux ! Etre payé leur suffirait ! |
TotalRecall |
--------------- Topic .Net - C# @ Prog |
uxam | lequel me conseillerez vous de compatible avec oracle ? Il faut qu'il soit simple avant tout Message cité 1 fois Message édité par uxam le 26-02-2009 à 13:26:41 --------------- PSN ID : Euronimus | Steam ID : [HFR] Euronimus | uplay: HFR_uxam |
masklinn í dag viðrar vel til loftárása |
--------------- Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody |
uxam |
--------------- PSN ID : Euronimus | Steam ID : [HFR] Euronimus | uplay: HFR_uxam |
TotalRecall | Personnellement je ne trouve pas que l'entity framework soit la merveille que certains décrivent par rapport à Linq to SQL. En gros si on a besoin d'accéder à autre chose qu'un SQL Server il n'y a que là qu'il devient avantageux (vu que c'est chose impossible avec Linq to sql). J'ai cru comprendre que l'entity framework V4 (à venir pour .Net 4 / VS2010) sera par contre plus intéressante mais je n'ai pas creusé, en attendant mes dév actuels s'appuient sur linq to sql. Une page qui compare (un peu) les deux : Message édité par TotalRecall le 17-06-2009 à 20:14:53 --------------- Topic .Net - C# @ Prog |
TotalRecall | Si le SGBD ciblé est SQLite c'est que tu ne vises pas un haut degré de performances ni de fonctionnalité, les contraintes ne sont pas les mêmes. Subsonic par exemple ferait sans doute bien l'affaire et il est simple à prendre en main... pour faire des choses simples. Par exemple L2SQL est pensé pour que tout enregistrement soit englobé dans une transaction, et il permet de gérer finement ce qui est chargé ou non avec un tuple lors d'un select (aussi bien au niveau des champs que des tables liées), alors que Subsonic tend plutôt à te faire faire des requêtes unitaires et est beaucoup moins souple sur le deuxieme point : c'est plus limité mais plus simple à utiliser. Ses propres limitations convergent donc peut être assez bien avec la philosophie de SQLite et ses restrictions. Je ne sais pas ce que vaut le provider SQLite de Subsonic mais il semble qu'il tienne la route. Message édité par TotalRecall le 05-07-2009 à 09:53:48 --------------- Topic .Net - C# @ Prog |
TotalRecall | edit : j'ai zappé un énorme détail... Subsonic 3 vient de sortir et à mon avis il y a du gros changement ! --------------- Topic .Net - C# @ Prog |
![]() Publicité | Posté le ![]() ![]() |