Reprise du message précédent :
Je voulais faire un topic sur les modeleurs UML à un moment mais j'ai pas eu d'adhésion .
Voilà quelques noms :
- Visual Paradigm (community edition gratuite)
- Modelio (version free gratuite)
- enterprise architect
VS 2010 introduit effectivement un modeleur, la démarche est louable mais le résultat pas encore au top. Il y a aussi des trucs pour l'améliorer, cf MS Visualization and Modeling Feature Pack. Personnellement je n'ai pas essayé (à titre pro je ne bosse pas encore sous vs2010) mais ça a l'air de valoir au moins un essai !!

Je regarderai tout ça !

update du premier post, qqes nouvelles libs référencées et des changements dans la forme (aération du message, p'tites étoiles devant les trucs qui valent vraiment le détour à mon goût)

Sympa cette première page.
 
Quelques remarque quand même :
 
NCover et NDepend sont (devenus) payants (sauf projet opensource).
Nant est par contre gratuit il me semble.
 
Sinon en outils qui peuvent être ajoutés :
CCNET > serveur d'intégration continue ccnet.thoughtworks.com
Gendarme > équivalent de FxCop mais du projet Mono http://www.mono-project.com/Gendarme

Merci, jferai ça à l'occasion.
Pour l'intégration continue, j'ai complètement fait l'impasse là dessus alors si tu as d'autres noms (ou trucs en rapport : plugins SCM, outils de build...) n'hésite pas !

Je n'ai utilisé que CCNET.
Outils de build, j'utilise msbuild.
 
Sinon pour la couverture de code, comme NCover est payant, j'utilise PartCover.
Il est pas aussi sexy que NCover mais c'est suffisant pour tourner sur un serveur d'IC.

Ajout de quelques outils sur la première page dont ceux cités ci-dessus .

Petit sujet de conversation : utilisez vous des frameworks généralistes comme Spring ou Castle (listés en première page) ?
 
Quels sont les composants incontournables selon vous, n'êtes vous pas dérangés par la quantité monstrueuse de trucs proposés en standard qui oblige à faire une sélection (pas forcément évidente étant donné les asm inter dépendantes) pour ne conserver que ce qui servira vraiment et ne pas avoir à déployer 30Mo de binaires sur le serveur ?
 
Personnellement je ne travaille pas avec, ou seulement avec des parties sélectionnées, pour faire de l'AOP et IoC par exemple et je regrette qu'on doive trainer tout le reste derrière en même temps.

Oui ma question se voulait volontairement vaste, quoi que je pensais bien à des frameworks additionnels qui viennent se greffer dans tous les coins (indispensables pour l'IoC par exemple) et pas à des patterns comme MVVM ou même MVC qu'on peut mettre en oeuvre sans en passer par là.
MS MVC (avec lequel j'ai pas mal bossé ces derniers temps d'ailleurs, pour le meilleur et pour le pire) je mets vraiment ça dans une catégorie à part, pour moi ça n'a rien à voir du tout alors si ma question t'y fait penser c'est que j'ai du mal la formuler.

Tu sembles dire que tu utilises Castle pour faire du MVC, càd ? Juste pour séparer les couches en saupoudrant d'un peu d'IoC là où ça peut servir ?
J'admets que côté "pur" MVC je ne sais pas ce que propose Castle.

Pour le côté perfs :
Spring c'est pareil que Castle par rapport à ta remarque.
L'IoC/DI sont de toute façon forcément des sources de ralentissement. Dès lors qu'on ne peut plus faire d'instanciation "naturelle" des objets mais qu'on s'en remet à des factories qui vont chercher par reflection ou un truc approchant les bonnes classes on plombe forcément les perfs.
Un peu pareil pour l'AOP dès qu'on fait du "methods boundaries" pour du logging par exemple.
Sachant qu'entre Castle, Spring et PostSharp (pour ne citer qu'eux), sauf erreur de ma part l'approche est très différente : PS fait de la post-compilation pour ajouter du MSIL où il faut, alors que les autres (?) passent par des classes "proxies" qui assument l'instanciation par reflection. Je ne sais pas si des benches ont été faits (c'est aussi l'objet de ma question ), mais je présume la solution PostSharp plus efficace...

En fait pour essayer de recentrer la question, on peut essayer de discuter de l'intérêt de ces frameworks (comparé à du bête Webform "natif" par exemple) et leurs inconvénients. Genre est ce qu'une grosse appli Webform "temps réel" peut être réécrite en IoC sans risque pour les perfs, afin de faciliter la mise en oeuvre de tests unitaires et le côté modulaire par exemple ?

PS : oui j'amalgame un peu Spring et Castle avec l'IoC en général mais bon, difficile d'aborder l'un sans l'autre !

Oui, en fait je sais que Monorail est l'un des composants de Castle (voir leur site pour la liste) et il est dédié au MVC mais le fw lui même englobe beaucoup d'autres trucs. Comme je disais je n'ai pas du tout essayé Monorail.

Pour l'IoC justement si je m'y intéresse en sollicitant des expériences concrètes c'est parce qu'on voit beaucoup de tutos théoriques avec des exemples de mise en oeuvre qui présentent les concepts mais pas beaucoup de "benchs code natif vs IoC mis en oeuvre au travers de X ou Y" ni d'exemple d'applis connues ayant une charge importante et s'appuyant dessus...

Si tu veux un outil qui te génére les interfaces à partir de la définition il y a Bonita Open Solution (open source) qui le fait. http://www.bonitasoft.com/

C''est du Java qui fait tourner un serveur Web pour les interfaces, par contre il y a la notion de connecteur qui te permet d'interfacer ça sur pas mal de chose (BD, ldap, envoi d'email, etc).

J'ai une question
 
Aujourd'hui (en 2010) est-il préférable pour un développement from scratch
 
 
- D'utiliser un ORM type NHibernate/Entity Framework/LINQ2SQL ?
- De développer son pseudo ORM (à l'ancienne) en utilisant ADO.Net + Procédures Stockées ?
 
Merci d'avance

 
 
Merci pour ta réponse
 
Cependant je suis tombé sur plusieurs articles qui descendent allègrement l'utilisation des ORM cités ci-dessus
J'ai l'impression qu'il y'a 2 écoles les pour et les contres et qu'au final il n'y a pas réellement de réponse concrète à cette question.
 
Mon problème se situe donc dans le choix a faire, avec ou sans ? Je n'ai aucun a priori sur la question mais un choix doit être fait

Les perfs de l'accès DB, ça peut parfaitement être une partie mineure du profil de perfs (genre parce que t'as des appels RPC qui défoncent complètement l'accès DB), ou les requêtes peuvent être franchement grosses auquel cas elles vont écraser la différences de perfs entre raw et ORM
 
Tu peux toujours forker ou upstreamer des patches si le projet est OSS.

 
 
 
Ben linq to nhibernate est quand même pas mal, même si encore limité (je dois travailler avec Oracle) : même si, c'est vrai, il y a des limitations un poil gênantes (genre : "join n'est pas implémenté", item.xx.ToLower() plante, ou d'autres trucs foireux), mais je pense qu'il va évoluer.
 
Ce que je trouve dommage avec NHibernate, c'est que tu as 3 moyens de générer des requêtes (hql, API Criteria, Linq), et que certaines fonctionnalités n'existent que pour une méthode : le "Future" de l'API Criteria, par exemple.
 
Sinon, pour le débat, entre quelques pertes de perf et "maintenabilité" sur plusieurs années (ce qui est le plus gros du boulot), le choix est vite fait.
 
Edit :
J'ai un collègue qui s'est lancé dans un "mini-ORM maison" pour un projet en attendant de savoir ce qu'on allait utiliser, ben c'est chouette, pas de doc, s'il se casse et qu'il faut faire évoluer le bousin ce sera un vrai bonheur !

Personnellement je suis aussi vivement contre le dév d'un ORM maison, à moins d'avoir 1 an devant vous avant la moindre livraison, des besoins ultra spécifiques, une équipe super compétente et un gros budget je trouve que ça ne rime à rien.

L'accès direct à la base est assez crade et complique la maintenance en cas d'évolution du schéma.
Les considérations de performances n'ont à mon sens pas à peser dans la balance, dans un projet "concret" la différence ORM/accès direct devient imperceptible et l'entity framework est très performant et se met en place en un clin d'oeil (j'en dirai pas autant de NHibernate !!) sur un nouveau projet quelque soit sa taille.

ORM et procstock peuvent très bien aller ensemble, selon les impératifs de performances et les pratiques en vigueur dans la boite (par exemple si vous avez des équipes SQL dédiées qui font tout à coup de PS et ne veulent pas entendre parler de la façon dont l'appli sera consommée) ça peut avoir du sens.

Concernant le choix EF ou NHibernate, je trouve ce premier très complet et facile à prendre en main (designer graphique, langage de requêtage très naturel), NHibernate est beaucoup plus lourd à mon goût. Il y a aussi Subsonic qui peut valoir le coup d'être examiné.

Il y a aussi les contraintes de connecteur à considérer selon le SGBDR consommé, par exemple le connecteur Oracle de Microsoft est à oublier, ce qui n'empeche pas d'en utiliser d'autres (il y en a plein, à tous les prix, dont celui d'Oracle eux même).

 

 
Merci a toi également pour ces explications Ca commence a prendre du sens dans mon esprit
 
Et je vois que pas mal d'entre vous préfère Entity a NHibernate je vais donc jetter un coup d'oeil a cet ORM la

Au passage auriez vous des liens de tutoriaux intéressant pour Entity Framework 4 ?

Merci beaucoup pour ton implication
 
Mais il semblerais que d'après ton discours il serait préférable que je me mette plutot sur EF3 que EF4 qui n'est pas encore trop utilisé dans le monde de l'entreprise ?
 
Car j'imagine que d'autres chose réalisable sous EF4 ne le sont pas sous EF3 et pourrais me poser des soucis
 
Je me trompe ?

 
 
En fait l'origine de mes questions viens du fait qu'actuellement je cherche un poste en tant qu'ingé .Net.  
 
Sachant que cela fait un an que je n'ai pas bossé et que lors de mes dernières expériences professionnelles, les ORM (NHibernate et EF) n'étais pas utilisés chez nos clients. C'étais plutot du dev .Net classique avec ProcStoc et pseudo ORM maison.
 
Donc je souhaite me préparer, vu que pas mal de SSII demande des compétences framework 3.5/4.0 + ORM type Hibernate ou EF

Oui je vais étudier le tuto que tu as posté de scottGuru, ça sera déjà une bonne base pour les fondamentaux.
 
Faudrait par la suite que je puisse trouver un tuto plus poussé, plus complet et plus proche du monde réel. N'étant pas un débutant en .Net (2.5ans d'XP) les tutos de base risque de me frustrer

Quel accent ...

 
Ha bon ? Pourquoi plutôt du client lourd ?
 
Perso je suis plutôt webForms, je n'ai fait que ca durant mes missions précédentes