Discussion :

[kunfuka]

Bonjour,

J'aurais aimé connaitre le niveau d'implantation de linq dans les projets actuellement.
Personnellement, je n'ai entendu aucun projet démarrer avec linq.

Donc si vous utilisez linq, quel est le domaine d'activité de l'entreprise, la durée du projet ?

Merci

[dev01]

Oui.

Nous l'utilisons en projet interne sur une version 2.0 d'un logiciel à usage interne. Toute la couche d'accès aux données est écrite avec linq to Sql et nous utilisons pas de Linq To object aussi

[anthyme]

moi sur un projet from scatch

Quand on a le choix de la 3.5 pourquoi se priver

[SaumonAgile]

+1

Utilisé pour des projets internes et externes dans la DAL

[Philippe Vialatte]

Pas de mon coté, vu que le passage a 2008 est encore dans les cartons...

Mais des que c'est fait, la DAL va en prendre un vilain coup (vive linq to XML et linq to Sharepoint!!!)

@SaumonAgile : tu as reussi a faire une belle DAL bien pensée, en linq to sql? Parce que de tout ce que j'ai vu trainer a droite a gauche, ca m'a l'air moyennement propre...

[anthyme]

Mais des que c'est fait, la DAL va en prendre un vilain coup (vive linq to XML et linq to Sharepoint!!!)

Ah je connaissais pas, cela permet quoi ?

@SaumonAgile : tu as reussi a faire une belle DAL bien pensée, en linq to sql? Parce que de tout ce que j'ai vu trainer a droite a gauche, ca m'a l'air moyennement propre...

Je suis dans les mêmes problématique en ce moment ... le context en lui même peut etre vu comme une sous partie de DAL je me demande si je vais par faire les selects dans ma couche BBL... Sinon y a les probleme de refresh/attach qui sont bien casse c... quand on sort du context ...

[Thomas Lebrun]

Moi, quand ca pose pas de pb avec les clients, j'utilise LINQ To * dès que je le peux

[SaumonAgile]

En fait j'expérimente beaucoup en ce moment sur un projet en interne. J'essaie de trouver la meilleure solution.
En fait je vais essayer de dégager des architectures différentes en fonction de la taille des projets.

Je suis sur un projet de petite taille pour lequel le MPD est assez proche du MCD pour ne pas avoir à recréer une abstraction par dessus les objets de la DAL.
La DAL et la BLL (ainsi que les entités) sont dans une même assembly. Le service WCF est une assembly séparée.
La DAL est composée du dbml (généré en internal) avec les entités générées (en public) dans un namespace différent. Une méthode est ajoutée au context pour gérer des connection string différentes en fonction de l'environnement (DEBUG, TEST, PROD).
La BLL se sert du contexte pour manipuler les données. La validation est faite d'un mélange de EL 4.0 Validation Block + PostSharp.

Le service WCF se sert de PostSharp pour toute la gestion des exceptions.

Voila mon ébauche d'architecture pour un projet de taille réduite (moins de 70 entités)

[kunfuka]

Je souhaitais tâter le terrain avant de quitter ma mission en septembre/octobre car le fait de travailler sur les nouveautés de C# 3 et du framework 3.5 pour la prochaine mission serait un gros plus.
Merci pour vos réponses.

[anthyme]

En fait j'expérimente beaucoup en ce moment sur un projet en interne. J'essaie de trouver la meilleure solution.
En fait je vais essayer de dégager des architectures différentes en fonction de la taille des projets.

Je suis sur un projet de petite taille pour lequel le MPD est assez proche du MCD pour ne pas avoir à recréer une abstraction par dessus les objets de la DAL.
La DAL et la BLL (ainsi que les entités) sont dans une même assembly. Le service WCF est une assembly séparée.
La DAL est composée du dbml (généré en internal) avec les entités générées (en public) dans un namespace différent. Une méthode est ajoutée au context pour gérer des connection string différentes en fonction de l'environnement (DEBUG, TEST, PROD).
La BLL se sert du contexte pour manipuler les données. La validation est faite d'un mélange de EL 4.0 Validation Block + PostSharp.

Le service WCF se sert de PostSharp pour toute la gestion des exceptions.

Voila mon ébauche d'architecture pour un projet de taille réduite (moins de 70 entités)

En fait ta DAL est uniquement Le DataContext ?

[rad_hass]

En fait j'expérimente beaucoup en ce moment sur un projet en interne. J'essaie de trouver la meilleure solution.
En fait je vais essayer de dégager des architectures différentes en fonction de la taille des projets.

Je suis sur un projet de petite taille pour lequel le MPD est assez proche du MCD pour ne pas avoir à recréer une abstraction par dessus les objets de la DAL.
La DAL et la BLL (ainsi que les entités) sont dans une même assembly. Le service WCF est une assembly séparée.
La DAL est composée du dbml (généré en internal) avec les entités générées (en public) dans un namespace différent. Une méthode est ajoutée au context pour gérer des connection string différentes en fonction de l'environnement (DEBUG, TEST, PROD).
La BLL se sert du contexte pour manipuler les données. La validation est faite d'un mélange de EL 4.0 Validation Block + PostSharp.

Le service WCF se sert de PostSharp pour toute la gestion des exceptions.

Voila mon ébauche d'architecture pour un projet de taille réduite (moins de 70 entités)

Bonjour,

Je voulais savoir quand tu parle d'entités ici, c'est bien dans le sens de EF ?
Quand tu dis "Les entités générées" elles sont générées par l'utilisation d'EDM ? Ou par un outil de génération de code ?
Sinon dernière question lol, quel est l'intérêt de mettre la DAL et la BLL dans un même assembly (ta réponse peut être effectivement quel est l'intérêt de les séparées lol).

Merci d'avance pour tes réponses (vos réponses).

[SaumonAgile]

Bonjour,

Je voulais savoir quand tu parle d'entités ici, c'est bien dans le sens de EF ?
Quand tu dis "Les entités générées" elles sont générées par l'utilisation d'EDM ? Ou par un outil de génération de code ?
Sinon dernière question lol, quel est l'intérêt de mettre la DAL et la BLL dans un même assembly (ta réponse peut être effectivement quel est l'intérêt de les séparées lol).

Je parle des entités LINQ to SQL générées à partir du dbml.
Je mets la DAL et la BLL dans la même assembly pour pouvoir rendre publiques mes entités et rendre internal le datacontext. Le context est donc accessible à la BLL tout en n'étant pas visible de l'extérieur de l'assembly.
De plus, la séparation logique des couches est tout à fait suffisante dans mon cas, je n'ai pas besoin de séparation physique (assemblies séparées).
Je pourrais séparer les couches dans des assemblies séparées si sqlmetal était capable de générer le context et les entités dans des fichiers séparés.

[rad_hass]

Je parle des entités LINQ to SQL générées à partir du dbml.
Je mets la DAL et la BLL dans la même assembly pour pouvoir rendre publiques mes entités et rendre internal le datacontext. Le context est donc accessible à la BLL tout en n'étant pas visible de l'extérieur de l'assembly.
De plus, la séparation logique des couches est tout à fait suffisante dans mon cas, je n'ai pas besoin de séparation physique (assemblies séparées).
Je pourrais séparer les couches dans des assemblies séparées si sqlmetal était capable de générer le context et les entités dans des fichiers séparés.

merci pour cette reponse complete

[B.AF]

Linq to SQL et EF : No hope
Ce sont des produits trop immatures, avec en plus une stratégie à moyen terme plus que flou.

Concernant le reste, Linq to Object oui, quoique nous ayons pu avoir quelques surprises.

Sachant qu'à priori nous avons un dal de plus de 600 entités et le double en business, une bonne cible à 2000~2500 services; une couche WCF / Remoting.

La récursivité est un sujet suffisamment critique pour nous pour que nous ayons abandonné depuis longtemps la croyance de l'ORM magique.

Linq et EF donne un contrôle plus que limité sur leur comportement (probablement la jeunesse) et finalement, l'usage de linq pour SQL est très dangereux dans certains cas.

EF en outre n'utilises pas de POCO, ce qui est un inconvénient majeur (comme d'autres outils), a une vision du chargement différé qui est tellement propriétaire qu'elle en devient incontrôlable, il y a un manque de support de DB diverses; et pire que tout; ca reste orienté relationnel.
Et dans une logique d'application d'entreprise à haute disponibilité,ces deux sous ensembles du FMWK sont pitoyables sur les aspects distribution.

[anthyme]

Linq to SQL et EF : No hope
Ce sont des produits trop immatures, avec en plus une stratégie à moyen terme plus que flou.

Microsoft a quand même annoncé que pour .Net 4 EF sera LA solution d'accès aux données mis en avant par rapport aux autres, donc je pense que niveau moyen et long terme c'est assez clair !

[B.AF]

Peut être, j'ai aussi tenu de long débats sur ce sujet avec Franz Bouma (autheur de LLBL).

D'un point de vue marketing EF est fabuleux,
D'un point de vue purement ORM, EF est un vide intersidéral.

Microsoft peut annoncer en tant qu'éditeur, l'adoption et la maturité d'un outil en sont d'autres.

Une fois de plus, les utilisateurs vont subir les aléas d'une conception ne tenant pas compte de la communauté (à quand l'EJB en .NET, ca aiderait.)

ADO.NET Data Services ? Linq to SQL ? ADO VNext ????

Ca s'éparpille dans des produits immatures qui font des démos sur northwind.
Je ne vois pas en quoi savoir que microsoft à (peut être) les idées claires sur sa politique d'accès aux données va faire avancer l'adoption aujourd'hui del a technologie.

Malheureusement, les projets ne vont pas attendre 3 ou 4 ans que la techno soit prête ou que Microsoft arrête de faire du Buzz sur l'accès aux données.

[anthyme]

Pour l'absence de poco je comprend que ce soit dommage surtout lorsqu'on a une architecture de 600 entités en place mais bon de la a dire que c'est un vide intersideral, il ne faut pas abuser ...

Le support des DB? EF est sortie en prod il y a uniquement un mois, les provider tiers sont en train d être écrit et certains sont finalisé voir gratuit dans certain cas ...

Pac contre je ne comprend pas ce que tu veux dire par orienté relationnel ? on a bien un mapping objet ... si tu parle de l'utilisation de linq par dessus personnellement je trouve que c'est un gros plus d'un point de vue lisibilité et productivité vis a vis de solution comme le HQL...

pour les EJB en .net j'espère que tu blagues ...

pour moi il manque 2 truc pour que ce soit le top c'est les poco et lazyloading mais bon ce n'est pas pour cela que nous avons un produit d'un vide intersidéral ...

Ces fonctionnalités seront intégré dans la V2 apres peut etre aurait tu préféré qu'ils sortent la V2 en premier mais bon la cela permet une migration et formations en douceur...

[rad_hass]

Je pense qu'attendre qu'un produit soit parfais (ou mature) dés la V1 c'est d'un optimisme exemplaire lol, d'ailleurs on peut constater que les EJB ont fait beaucoup de chemin depuis la V1 (de plus on est à la V3 et le produit est encore critiqué) ...

[B.AF]

"Je pense qu'attendre qu'un produit soit parfais (ou mature) dés la V1 c'est d'un optimisme exemplaire lol, d'ailleurs on peut constater que les EJB ont fait beaucoup de chemin depuis la V1 (de plus on est à la V3 et le produit est encore critiqué) ... "

A partir du moment ou un éditeur pose dans son offre une fonctionnalité dite de niveau "entreprise", c'est lui qui fait le choix de la cosidérer aboutie et répondant au besoin de ses clients. EF est dans 2008 SP1.

Quant aux EJB ,l'exemple est plutôt à prendre dans le fait que la communauté puisse plus ou moins bien influer sur l'évolution du framework que d'attendre les yeux brillants le fruit de la créativité d'un éditeur.

Et sur la critique des EJB, on sera hors contexte ici puisqu'il faudrait surtout faire le débat de l'existence des "développeurs" et "programmeurs". Ceux qui font et ceux qui attendent que les autres fassent pour s'en servir.

[rad_hass]

A partir du moment ou un éditeur pose dans son offre une fonctionnalité dite de niveau "entreprise", c'est lui qui fait le choix de la cosidérer aboutie et répondant au besoin de ses clients. EF est dans 2008 SP1.

Je comprends tout à fait ton point de vue et je pense que y a du vrai dans ce que tu dis, mais néanmoins tu ne penses pas que si un produit réponds de 70 à 80% des besoins projets (et réponds moins bien au projet les plus pointue et les plus complexes), 3 mois seulement après sa sortie je pense que c'est une technologie prometteuse ... Non un vide intersidéral lol

Et je ne pense pas que la communauté .NET ne soit si ignoré que tu le suggère, il est vrai que Microsoft a encore des efforts à faire, mais je pense que le poids de la communauté est de plus en plus présent ...