Discussion :

[Invité]

Bonjour à tous,

Je fais appel à vous aujourd'hui pour avoir votre avis sur une architecture de logiciel.

Je travaille actuellement sur une application WPF qui communique avec un Service WCF, qui lui même utilise Entity Framework pour travailler avec la BDD.
L'application WPF a été développée en utilisant MEF et MVVM Light.

Voici un petit plan de l'architecture de l'application actuellement :

Commun
- Core
- Shell

UI
- Module1.UI
- Module2.UI

Services
Module1
- Data
- Interface
- Process
Module2
- Data
- Interface
- Process

On a donc un projet Shell qui fait office de Launcher. C'est une coquille vide (enfin pas totalement lol) qui se charge de récupérer les dll des différents modules grâce à MEF.
L'utilisateur a donc un menu pour lancer et afficher chaque module (le module est chargé lors du premier lancement).

Côté UI, chaque module est donc dans un projet bien distinct. Chaque Module possède une référence vers un service.

Au début du développement, on a fait le choix de faire un Service WCF par Module pour avoir une séparation totale entre les modules.
Chaque module possède sur le service 3 projets : un projet Data qui contient l'Edmx, une Interface et un Process. Du classique pour faire du WCF.

Au départ, ce système paraissait très bien. Malheureusement, la réalité est souvent un peu différente. On pensait à l'origine que chaque Module serait complétement indépendant de l'autre.
En réalité, il y a beaucoup d'interconnexion. Par exemple, les différents Edmx référencent beaucoup de table en commun. Au quotidien, si on modif la BDD, on doit donc mettre à jour plusieurs Edmx.
On se retrouve également avec des méthodes dans les process en commun. Il y aurait beaucoup de possibilité de factorisation.

Même du côté UI, on se retrouve avec du code en commun. Par exemple, on a pas mal de Converters identiques parmis les Modules. Malheureusement, on ne peut pas les déplacer dans le Core car ces Converters travaillent sur des entités de l'Edmx. (Le core ne possède aucune référence de Service et n'a donc pas conscience des entités).

Je fais donc appel à vos lumières pour avoir des suggestions / avis. Faut il revoir le système du côté du service ? J'avais imaginé de ne faire qu'un seul service ou, au moins, de n'avoir qu'un seul Edmx.

A titre informatif, je dirais qu'au total il y a une 50aine de tables (si on combine tout) et que chaque process comporte environ 2000/3000 lignes de code.

Merci d'avance pour votre aide et vos suggestions.

[Nathanael Marchand]

Pour le coup, j'aurais fait un edmx commun dans un seul projet pour tout le monde. Sinon, le reste du découpage m'a l'air pas mal

[NicoL__]

Le problème de l'architecture d'un module c'est sa conception monobloc. En fait la responsabilité du module est défini par son interface. Or les couches en dessous (process et data) n'ont pas vraiment de raison d'exprimer cette responsabilitée et ont une granularité plus fine : des responsabilité plus simple et d'ordre plus technique et sont probablement réutilisables pour implémenter l'interface d'un autre module...

En théorie les couches les plus basses devraient avoir la granularité la plus fine, plus élémentaire et ayant une responsabilité plus technique que métier.
En suite on construit la couche supérieur, en utilisant ces dll sans qu'elles soient connotées par une responsabilité du niveau d'un module. Et on peut ainsi les réutiliser de module en module.

Pour moi la limite d'un edmx ce sont les liens (foreign key) entre les tables, il vaut mieux éviter de les couper d'un edmx à l'autre. Mais s'il n y a pas de lien potentiellement c'est un groupe de tables qui pourrait être migré dans une autre base donc il vaut mieux avoir un edmx indépendant.