Discussion :

[miltone]

Salut à tous,

Étant dans l'étude du monde Microsoft et surtout du .NET, j'ai remarqué que mes sources d'informations parlaient souvent de conception que je n'arrive pas à comprendre. Cela semble acquis pour tellement de monde que finalement personne les détails ou les expliques.

========================================================

J'aimerais comprendre ce qu'est un context en C#. On parle souvent de cette notion dès qu'il s'agit de manipulation de données mais je n'arrive pas à le concevoir dans ma tête. Comment pourriez-vous vous me l'expliquer et surtout me l'imager ?

---------------------------

Concernant les couches, j'ai constaté qu'un bon programmeur, programme toujours par couche. Mais concrètement qu'est ce qu'une couche ?
J'ai remarqué lors d'un webcast des techDays 2010, pendant une explication sur Entity framework, la personne montrait son VS et mentionnaient des couches en montrant à chaque fois un projet qui était imbriqué dans sa solution.
Peut-on considérer une couche comme un projet à par entière dans une solution ?

----------------------------

Pour finir, j'ai une conception et un apprentissage plutôt graphique des choses. Avec toutes les imbrications possible qui existent dans .NET, j'aimerais savoir s'il existe un outil ou plugins pour VS qui puisse générer des schémas UML suivant le code source du projet ou de la solution ?

======================================================

En espérant que vous pussiez m'aider, je vous remercie d'avance de votre soutien....

[tomlev]

J'aimerais comprendre ce qu'est un context en C#. On parle souvent de cette notion dès qu'il s'agit de manipulation de données mais je n'arrive pas à le concevoir dans ma tête. Comment pourriez-vous vous me l'expliquer et surtout me l'imager ?

Ce n'est pas un concept C#... tu parles probablement du contexte dans le cadre de l'utilisation de Linq to SQL ou Entity Framework ? En gros, c'est l'objet qui gère la connexion à la base de données, la transformation des requêtes Linq en requêtes SQL, la matérialisation des objets, le suivi de leurs modifications, etc.

Concernant les couches, j'ai constaté qu'un bon programmeur, programme toujours par couche. Mais concrètement qu'est ce qu'une couche ?
J'ai remarqué lors d'un webcast des techDays 2010, pendant une explication sur Entity framework, la personne montrait son VS et mentionnaient des couches en montrant à chaque fois un projet qui était imbriqué dans sa solution.
Peut-on considérer une couche comme un projet à par entière dans une solution ?

En pratique, chaque couche est effectivement matérialisée par un projet distinct dans la solution. Mais ce n'est pas parce que ta solution a plusieurs projets que tu fais un développement en couches

En gros, le principe est de bien séparer les responsabilités entre les différentes parties du projet, et de faire abstraction de l'implémentation réelle de chaque partie quand tu l'utilises, pour réduire le couplage. De cette façon, tu peux par exemple remplacer ta couche d'accès au données utilisant Linq to SQL par une autre qui utilise NHibernate, sans rien modifier aux autres couches ou presque (ou même pas presque, si tu utilises l'injection de dépendance...)

Voilà un petit tuto qui devrait t'intéresser :
http://morpheus.developpez.com/architecture/

Pour finir, j'ai une conception et un apprentissage plutôt graphique des choses. Avec toutes les imbrications possible qui existent dans .NET, j'aimerais savoir s'il existe un outil ou plugins pour VS qui puisse générer des schémas UML suivant le code source du projet ou de la solution ?

Visual Studio peut te générer un diagramme de classes automatiquement : ajoute à ton projet un élément de type "diagramme de classes", et fais-y glisser les classes que tu veux afficher à partir de la vue des classes.

Sinon, la version Ultimate de VS2010 intègre un éditeur UML, mais je ne sais pas si ça peut automatiquement générer les schémas à partir du code...

A tout hasard, si tu as VS2010, regarde dans le gestionnaire d'extensions s'il n'existe pas des extensions pour faire ça

[miltone]

Après lecture de la documentation que tu m'a mentionné sur les couches il y a un point que je n'ai pas bien compris.

Il s'agit de la couche BO (Business Objects). A quoi sert-elle exactement ?
J'ai compris la couche BLL mais la BO....
Est-ce le résultat de mon Object Relationnal Modeling que je peux effectuer grâce à Entity Framework ?

Pourrais-tu m'expliquer simplement et de façon généraliste ce qu'est l'injection de dépendance ?

Sinon pour finir, ok j'ai bien compris le système de couche mais existe t-il des subtilités à .NET pour lesquels la documentation serait en erreur ?
Puis-je prendre cette doc comme très bonne référence solide ?

[tomlev]

Il s'agit de la couche BO (Business Objects). A quoi sert-elle exactement ?
J'ai compris la couche BLL mais la BO....
Est-ce le résultat de mon Object Relationnal Modeling que je peux effectuer grâce à Entity Framework ?

Les "business objects", c'est tes entités métier (un client, une commande, une facture...)

Par rapport à Entity Framework, je sais pas très bien en fait... les ORM comme EF ou NHibernate ont un peu tendance à "flouter" la limite entre entités métier et objets d'accès aux données. N'étant pas expert en la matière, je préfère m'abstenir de répondre pour ne pas te dire de bêtises

Pourrais-tu m'expliquer simplement et de façon généraliste ce qu'est l'injection de dépendance ?

Encore une fois, je suis pas vraiment la meilleure personne pour te répondre... Tu devrais trouver une bonne explication ici :
http://philippe.developpez.com/artic...LIDdotNet/#LVI
(ça parle en fait d'inversion de dépendance, qui est un concept plus large que l'injection de dépendance... jette un coup d'oeil à Wikipedia pour plus de détails)

Sinon pour finir, ok j'ai bien compris le système de couche mais existe t-il des subtilités à .NET pour lesquels la documentation serait en erreur ?
Puis-je prendre cette doc comme très bonne référence solide ?

Ben ça reste un article "amateur", mais écrit par quelqu'un qui sait de quoi il parle, donc normalement ça doit pas dire trop de bêtises
Après, il n'y a pas une approche unique du développement en couche, tu peux trouver toutes sortes de variantes. Donc je ne pense pas qu'il existe vraiment une référence unique en la matière...

Désolé, mes réponses sont un peu floues
Mais bon, l'architecture logicielle n'est pas vraiment une science exacte

[miltone]

Merci encore Tomlev pour toutes ces informations.
Je clos le sujet comme résolu et je vais poster un nouveau sujet concernant la couche BO.

A la prochaine....

[Nathanael Marchand]

L'essentiel dans une architecture c'est qu'elle réponde le mieux à tes besoins, pas d'être l'archi standard best practice!

[miltone]

Je suis dans l'apprentissage de la plateforme .NET et j'ai besoin de savoir comment faire de bonnes fondations avant de me lancer dans la construction de ma maison.

Sinon je peux résumer le développement de mon programme à ca plus simple expression et je ne pense pas que cela soit une bonne solution à terme et pour se former à .NET.

Donc tu as raison PitMaverick78 si toutefois on connait déjà un peu le développement professionnel et le .NET mais si on part de zéro il n'est pas vraiment conseillé d'en faire qu'a ca tête et de faire une application qui se contente de marché à un instant t "bêtement".