Reprise du message précédent :
Non, non, non, bof.
 
Ok

Les webservices en WCF franchement, c'est pas ce que je ferais aujourd'hui. REST oui OK et dans ce cas-là voir ce qu'est WebAPI. Mais WCF pour servir uniquement du HTTP, c'est pas terrible.
 
Idem, Entity Framework pour une DAL... c'est l'artillerie lourde.  
 
Hephaestos, tu sais avec quels frameworks/technos tu vas bosser ?

Autant je suis d'accord pour WCF, autant je vois pas la raison de se priver d'EF.

 
Se priver d'EF ? dès lors que la bdd n'est pas SQL server, vaut mieux
 

A ce point ? C'est vrai que j'ai toujours fait du SQL Server
 
Est sinon tu refait une bonne vielle DAL avec ADO.NET ?

 
Nhibernate marche (marchait?) pas mal avec oracle.
 
J'ai un projet qui commence et il me faut un ORM pour DB2, j'étais parti sur EF également mais vous avez peut-être d'autres recommandations ?

 
Hooo oui... je me suis essayé à faire de l'EF avec Oracle (via connecteur DevArt Dotconnect), avec Sybase, ou encore Sqlite, et à chaque fois j'ai regretté... Il y a plein de fonctionnalités qui remontent des jolis NotImplementedException au runtime    
 
Au final, faut tellement bricoler le truc pour que ça marche que tu regrette amèrement ne pas avoir utiliser un bon vieil ADO.NET.
 
Sinon, Nhibernate est tout indiqué aussi

Perso j'ai commencé à jouer avec Dapper. Avec Dapper.FastCRUD et son template pour générer les modèles à partir de la DB, il y a moyen de jouer à partir de MSSQL, MySQL, PostgreSQL et un 4è (SQLite?) sans y perdre trop en perfs par rapport à ADO.NET. Mais je suis qu'au début donc j'ai à peine survolé pour l'instant.

 
Devoir réécrire toutes les requêtes SQL    
 
NHibernate j'ai utilisé une fois, j'ai un peu regretté le manque de doc à l'époque.

Intéressante la discussion

+1 avec Dapper, des perfs exceptionnelles. On l'a utilisé avec SQLite et Sybase.

C'est très loin d'être déconnant si tout ce que tu fais c'est du pauvre CRUD comme dans 90% des applis et je parle même pas des fichiers XML de requêtes où tu retrouves de toute façon tes requêtes SQL, ou des appels aux procédures stockées. Idem si tu veux faire des batches d'insert (ligne à ligne ? avec ou sans transaction ?) ou des copies de base à base, les ORM n'ont que très peu de valeur (voire sont destructeurs en termes de perfs ou fiabilité en fonction du SGBD utilisé). Et vu le changement de paradigme introduit par SQL vs les langages objet, je trouve qu'il est vivement conseillé de connaître SQL avant de se lancer dans des manipulations d'objets, ne serait-ce que pour faire partir la magie.
Un ORM c'est souvent overkill et ça fait vite des requêtes SQL pourries, sans parler des DTOs qui ne sont que des objets conteneurs. D'ailleurs, voici un article intéressant sur le sujet des ORM et l'orienté objet. Les bouts de code sont en Java mais je suis sûr que vous pourrez raccrocher les wagons avec C#

Personne ne fait de LinqToSQL ?

Encore une fois ça dépend énormément de ce sur quoi il va bosser. REST/WebAPI c'est très bien dans un contexte web, mais pour de la communication réseau "interne" SOAP et WCF n'ont pas encore été détrônés, désolé. Et WCF permet d'exposer en quelques lignes des bindings qui échangent du JSON.
C'est une techno très puissante (bien que lourdingue si tu cherches à faire des trucs compliqués ou de la sécurité poussée), robuste, et très présente sur le marché. Donc je ne pense pas que ça soit du temps perdu.

Quant à l'EF, y toucher ça veut dire se former d'une part à LINQ (to objects inclus), et aux ORM : ce sont des compétences très profitables également. Même si effectivement c'est avec SQL Server que l'EF s'en sort le mieux ça n'est en aucun cas du temps perdu...

On peut tout à fait affiner si hephaistos nous en dit plus sur sa future affectation mais sans ces précisions je pense avoir été de bon conseil pour découvrir les solutions du framework par des trucs à la fois puissants et très utilisés.

Je ne dis pas que tous les projets doivent être faits avec l'EF et WCF, mais que quitte à commencer en C# autant se pencher là dessus (sans parler de devenir expert, juste faire un PoC quoi)...

Pour moi si tu cibles SQL Server et si tu veux utiliser un ORM l'EF est un excellent choix à l'heure actuelle et les requêtes qu'il génère sont très souvent efficaces, surtout que tu as pas mal de leviers d'optimisations (qui nécessitent de bien connaître l'outil, certes).
 
Par contre je rejoins ixemul dès que tu veux utiliser un SGBDR moins bien implémenté, j'en ai fait la pénible expérience aussi avec du SQLite .
 

Ca pour le coup c'est outdated par contre .
Ca fonctionne encore plutôt bien avec du SQL Server cela dit, et pour de petits projets simples c'est plus facile et plus stable que l'EF, surtout avec les vieilles versions de Visual Studio où l'EF avait tendance à déconner pas mal (sous vs 2008 l'EF c'était pas trop ça ).
 
Mais j'en ai fait des années... Pourquoi tu demandes ?

Tu m'as quoté mais je le remets en évidence :

WCF est intéressant quand tu fais par exemple du TCP  ou d'autres protocoles. Pour du HTTP pur, dans un contexte back end (donc avec un front end que j'imagine en JS), je maintiens que WCF c'est vraiment pas (plus) le top.

Bof. J'ai très peu touché à EF dans mon XP pro, ça m'a jamais desservi. Ca reste un framework, ça peut s'apprendre sur le tas. Les ORM pareil, nonobstant mon post précédent.
Linq, y a plein d'autres façons de l'apprendre.  

Pour moi, conseiller de tester tel ou tel framework est intéressant pour ratisser large dans le cadre d'une recherche d'emploi. Là, j'ai cru comprendre que le job était trouvé, donc conseiller de jouer avec EF ou WCF sans en savoir plus sur le contexte, c'est pas forcément de bon aloi.
Autant sur tout ce qui est injection de dépendances, OK. Si Hephaestos n'en a jamais fait (ce qui est probable venant du C++), je conseillerais de commencer par ça peu importe le framework. C'est vite indispensable dès qu'on veut faire un peu de code clean. D'ailleurs, Hephaestos, si tu l'as pas déjà lu : http://www.amazon.fr/Clean-Code-Ha [...] 0132350882

Parce que j'en utilise. A la base, sur un projet ou je devais faire des tirages aléatoires par millions et manipuler pas mal de collections et de tris (en mémoire, pas en bdd). J'avais rien trouvé de plus performant que Linq en mode parallèle pour gérer tout ça.
J'ai eu un autre projet derrière, pas d'une grande envergure mais dont les données était stockées en SQL Server selon un schéma sur lequel je n'avais pas la main.
Performances désastreuses en mode connecté pour LinqToSQL, mais sinon c'était un moyen simple d'accéder aux données et faire des calculs avant de tout renvoyer.
Je me demandais si c'était beaucoup utilisé.

Parce que l'ORM, c'est bien beau si on a la main sur toute la conception non ? Si on doit se greffer à un schéma, on a un peu les mains liées ...

Je ne vois pas le rapport entre ORM et schéma ? Tu ne définis pas ton schéma en fonction de si tu comptes utiliser un ORM ou non !
Un mauvais schéma sera toujours mauvais, même si un ORM limitera les possibilités d'optimisation (qui ne sont de tte façon que des moyens de contourner les défauts du truc).

qu'entend tu par "mode connecté" ? Les perfs de Linq2SQL sont loin d'être dégueu, sauf
- schéma dégueulasse et mal optimisé (index, stats, fk, etc. Mais ADO ne fera pas mieux évidemment)
- requête hyper complexe que l'ORM gère mal,
- traversage d'une arborescence complexes sur les objets ramenés sans un LoadWith approprié au moment d'émettre la requête
- Bulk insert/update (pas la tasse de thé des ORM, c'est pas fait pour)
- Mauvaise gestion du cycle de vie du datacontext

Et oui je pense que ça été bcp utilisé pendant longtemps en environnement SQL Server. Sauf pour les boites où la philosophie était d'avoir toute l'intelligence en base (procédures stockées monstrueuses et cie).
L'EF a pris la relève mais reprend les grands principes de L2S avec en plus les providers pour d'autres sgbdr, plus de possibilités d'optimisation, et un plus grand contrôle sur le modèle généré (héritage et abstraction plus faciles à mettre en oeuvre, etc).

 
 
Les mecs qui apprennent sur le tas EF, c'est justement eux qui font des trucs bien pourris et pas optimisés    
 
 
Le gain de temps en développement et maintenance est vraiment énorme avec EF vs DAL ADO.NET

Merci, je me sens moins seul d'un coup
Et puis franchement, entre écrire à la main ses requêtes C(R)UD et passer par un ORM, y a pas photo en terme de confort.
 
Vous avez déjà eu à remanier en profondeur un schéma de plusieurs centaines de tables où tout est fait avec des procédures stockées, y compris les bêtes inserts ? Moi oui. Essayez et on reparlera de l'intérêt des ORM...

C'est un projet tout neuf, donc ça reste ouvert. Ce sera du MVC en principe, hébergé sur une plateforme Azure. Après clairement l'aspect web ce sera pas à ma charge dans un premier temps, mais j'aimerais au moins connaitre le language et avoir une idée de l'écosystème avant de me lancer...

À force d'en entendre ou d'en lire des extraits j'ai l'impression de l'avoir lu, mais bon ouais il serait peut-être temps de le faire pour de vrai, mais ça va pas m'avancer pour mon expertise du C# !!!

Non, c'est clair. Et je ne vois pas l'intérêt de bloquer comme ça sur des concepts comme la DI qui pour être profitables requièrent de toute façon de déjà bien maitriser un minimum le langage et l'archi logicielle. Faire de la DI alors qu'on débute c'est se compliquer la vie et le code sans valeur ajoutée.
Fais déjà marcher un truc concret avant de faire abstrait...

Par contre tu viens de parler d'Azure et de MVC, ça nous éloigne de ce que tu disais sur la page précédente, même si c'est pas toi qui t'occupe de cette partie là. Concrètement tu feras quoi ? Si c'est en environnement Azure il y a déjà pas mal de contraintes...

Concrètement j'écris les programme qui prends des données, les traite, les analyse, et fournit un résultat. Je pourrais le faire en C++, mais ça n'apportera rien. Je pense que je n'aurai pas grand chose de + à faire que si j'écrivais une application desktop, à part m'interfacer au service web qui sera fait par mon binome.

Donc tu consommeras un service dans Azure ? Tu devras gérer de la persistance (DB) ou c'est du calcul "à la volée" ?
Essaie de savoir si tu dois faire du webapi ou autre pour orienter ta formation...

Je me recite :

Dans la plupart des applis sur lesquelles j'ai eu à intervenir, c'était du CRUD simple et utiliser NHibernate ou autre chose c'était se faire bien chier pour pas grand-chose. Si t'as des cas où utiliser un ORM t'a sauvé la vie ba tant mieux, mais pour une DAL "idiote", utiliser une usine à gaz comme NHibernate ou EF, franchement c'est se tirer une balle dans le pied. Entre la config, la complexité accidentelle que ça introduit (je mets aussi le lien vers le papier "Out of the Tar Pit" mais faut être motivé pour le lire ) et la courbe d'apprentissage (et je passe sur les problèmes de patterns objet mentionnés au préalable), j'ai tendance à penser que c'est pas souvent un bon choix dans la majorité des cas.

Lis-le, ça te servira toute ta vie de dev

Tiens j'ai pas encore regardé mais y'a moyen de jouer avec Linq sur Dapper? Apparemment non mais j'vois une extension et j'aime assez bien Linq. Mais j'ai peur pour quand j'aurai envie de faire autre chose que du SQL Server

Me souviens pu, stait en octobre pour (justement) faire une DAL à la con avec des pauvres SELECT, je sais plus ce qu'on a fait exactement. Je regarderai à l'occase, si tu veux.

En fait ma seule expérience de Linq, c'était avec EF justement. A vous lire j'ai pas l'impression que c'était top
 
Et j'ai aussi fait du WCF avec JSON

J'ai fait ce genre de missions. C'est généralement de l’algorithmie pure de traitement : on reçoit des données en entrée sur un connecteur, on les traite et on les rends une fois enrichies sur un autre connecteur.

Domaine industriel ? Si c'est le cas, il y aura peut-être du WCF mais très peu probable d'avoir du WebAPI. Sinon les connecteurs seront déjà développés (ex: MSMQueue, FTP, File, .Net Remoting), sans quoi ils ne feraient pas appel à toi. Par contre il est possible que tu ais à t'interfacer avec des bases de données via ADO.Net.
Vu que tu seras avec un binôme, tu n'as pas à te prendre la tête. Sache juste qu'avec le C#, tu as accès à tout le Framework .Net et n'a donc pas besoin de réinventer la roue pour accéder à des fichiers par exemple.

Tu peux jeter à œil à comment utiliser certaines particularités du langage, comme l'instruction 'using' ( https://msdn.microsoft.com/fr-fr/library/yh598w02.aspx ), le threading ( https://msdn.microsoft.com/en-us/li [...] 03-19.aspx )

Guide de programmation C# : https://msdn.microsoft.com/fr-fr/library/67ef8sbd.aspx

Si vraiment besoin de WebAPI : http://www.asp.net/web-api
Et pendant qu'on y est, des tutos MVC bien fais : http://www.asp.net/mvc

 
   
 
J'utilise Linq en permanence maintenant, ça remplace des foreach/if/break comme c'est pas permis, ça permet de faire du yeld return en une ligne, c'est magique.
 
je pourrais plus m'en passer  

Je voulais dire LinqToSQL (je m'y perds un peu) vu que je m'en servais pour construire des requêtes customs à côté de l'aspect classique ORM.
 
Sinon c'est clair, je vais pas assez loin dans mon usage de Linq

Pareil, j'ai jamais bien compris la différence entre ces outils (Linq tout court, LinqToSql, LinqToEntity, les lambda expressions etc...)

 
T'imagines même pas la joie qu'on éprouve quand on code un export CSV en une seule ligne de code avec Linq    
 
Bon, faut pas faire ce genre de chose en prod hein, mais juste pour la beauté du geste

Voilà, c'est comme coder un raytracer en une seule instruction linq, c'est possible mais faut pas être net

 
Le regarde perdu du mec qui passe derrière en maintenance du code

 
OK donc j'éviterai si je veux pas être pendu par les couilles

 
remember : http://blogs.msdn.com/b/lukeh/arch [...] racer.aspx (et encore, il aurait pu s'affranchir des 2 foreach imbriqués à la fin pour le rendu avec un .ToList().Foreach(x=> x.Foreach(Y => Setpixel()) )  
 

 
Vrais savent  

 
Mais t'imagine même pas la puissance du truc, en une ligne tu tries ta liste, tu la parcours et tu sors un FirstOrDefault et hop ! 6 Lignes de code en une seule, très lisible

[quotemsg=2276663,1499,51443]Merci, je me sens moins seul d'un coup
[quotemsg]
 
T'es loin t'es seul, et c'est plutôt la première fois que j'entends un discours comme celui de Taiche  

Les lambdas : j'utilise ça tous les jours quand je fais du C#. Dès que tu as quelque chose d'énumérable !