Architecture pour développement d'application SOLID

Bonjour à tous !

J'aimerais partager avec vous un article que j'ai écris traitant d'une méthode pour mettre en place des architectures modulaires à couplage faible en .NET (C#) : http://aurelien.boudoux.fr/2014/09/l...es-pierre.html

une version en anglais est aussi disponible sur codeproject : http://www.codeproject.com/Articles/...OLID-architect

Le sujet peut paraître complexe, mais je pense qu'il est incontournable si vous travaillez sur des applications métiers qui doivent évoluer très souvent.

J'espère que ça intéressera quelques personnes :)

@+

hmm interessant,

J'ai parcourus tres vite fait le billet car il est tres long, cela merite une lecture plus assidue et reposee que je ferai des que possible. :plusser:

Ok, la solution de l'interface est bien et n'est pas techno/lib dependante, mais:

Comment fais-tu pour transformer tes objets lorsque la structure est differente:

• Une personne a une liste de telephone cotemetier a un seul telephone cote flux.
• A partir d'un client, suivant sa position geopgraphique il faut utiliser son code postal ou son code insee
• Pour un flux il faut passer les boolens an OUI/NON

Je sais tres bien que la derniere question n'a pas grand chose a voir avec la transformation au sein de ta couche metier, mais si elle est sortie ailleurs, cela fait encore plus de transformations a gerer et un cout donc.

Hello,
J’ai tellement de réponses possibles que je ne sais pas quoi commencer :D

Je me lance…

Tout d’abord, l’esprit de la transformation de données consiste à remplacer le couplage fort qu’il peut exister entre 2 domaines (genre le métier qui fait un chargement dans la base de données) pour faciliter la substitution ainsi que les implémentations spécifiques à chaque domaine.
Dans ce contexte, transformer des objets dont les structures sont différentes n’est pas quelque chose de logique, « sauf » si un domaine désire posséder une version allégée d’un objet (mais dans ce cas, les structures ne sont pas réellement différentes).
Pour cela, il suffit donc de faire de la ségrégation d’interface, et le tour est joué.
Exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

public interface IPersonneLight { string Nom { get; set; } string Prenom { get; set; } }   public interface IPersonne : IPersonneLight { int Age { get; set; } string Adresse { get; set; } }

---

Ici j’ai un contrat de personne complet, mais je désire seulement le nom et le prénom lorsque je le charge depuis un autre module.
Dans ce cas, le module A peut implémenter IPersonne tandis que le module B implémente IPersonneLight, la transformation se passera sans problème !

Mais revenons à la question initiale, comment je fais si j’ai un module A dont la personne à une liste de téléphones, et un module B qui n’a besoin que d’un seul téléphone ?
Comme tu le dis, ceci n’est pas un problème de transformation, mais un problème de conception générale, je m’explique :

Imaginons une application dans laquelle j’édite un dossier client, celui-ci possède plusieurs téléphones.
On me demande dans ce dossier d’ajouter un bouton en bas à droite nommé « Envoyer un SMS ».

L’envoi de SMS est un module à part qui n’a besoin que d’un téléphone. Oui mais lequel ?
Pour répondre à cette question il doit forcément y avoir du code, ceci ne peut donc pas faire partie de la transformation, mais plutôt être de la responsabilité d’un service qui lui-même appellera un repository.

Exemple :

Le module SMS expose un repository

Code:

---

1 2 3 4

public interface ISmsRepository { void SendSms(string destinataire, string contenu); }

---

Et dans la partie métier, je n’ai plus qu’à mettre en place ma logique pour obtenir le bon téléphone et le contenu:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

public interface ISmsService { void SendSms(BolClient client); }   public class SmsService : ISmsService { private readonly ISmsRepository _smsRepository;   public SmsService(ISmsRepository smsRepository) { if (smsRepository == null) throw new ArgumentNullException("smsRepository"); _smsRepository = smsRepository; }   public void SendSms(BolClient client) { _smsRepository.SendSms(client.Telephones.First(a => a.StartWith("06")), client.Commentaire); } }

---

Nous ne sommes donc pas dans une problématique de transfert d’objet (DTO) mais bien d’appel de commande.
La transformation de données sert à régler la problématique de transfert, pour tout le reste il faut s’en référer aux bonnes pratiques d’architectures générales.

J’espère avoir été clair car le sujet est assez touffu en fait :p