Discussion :

[quentin869]

Bonjour, voila depuis quelque temps je me pose pas mal de question sur l'architecture n-tiers et le patern MVVM.

Je suis actuellement sur un projet qui implémente MVVM light et une architecture n-tiers, je vais vous décrire comment se présente mon projet ci-dessous.

Mon projet ce présente comme suis :

3 Solution

_ TierseManager.Behaviors (modèle DTO)

_ TierseManager.Core (c'est ici que j'effectue tous le travail BLL ?)

_ TierseManager (IHM)

TierseManager.Behaviors contient toute mes entités.

TierseManager.Core c'est ici que j'effectue tout le travail, récupération de données sur internet, connexion sur des sites, enfin vraiment tout le traitement ce fait dans ce projet.

TierseManager c'est ma couche présentation qui contient mes vues, vues-model (fait le lien entre ma vue et TierseManager.Core).

Je souhaiterais connaitre vos avis sur cette organisation, est-il possible d'amélioré tout cela ?

Une autre question qui me trotte dans la tête, actuellement les actions de mes boutons son bindé via RelayCommand dans mon View-Model et ensuite passer dans mon projet TierseManager.Core est-ce la bonne solution ?

Je vous remercie d'avance, Quentin.

[chamamo]

Personnellement j'aurais séparé les ViewModels et les Views, je metterais les vues dans une nouvelles assembly TierseManager.Views.
Prenons un exemple, tu vas choisir par exemple de faire l'IHM en WPF, un jour un te demande de passer à Silverlight, tu vas pouvoir réutiliser tes ViewModels.

La communication entre les couches passe par des interfaces, pour pouvoir tester chaque couche séparément et pouvoir changer les implémentations facilement (passer de WPF à Silverlight par exemple ou Windows phone).

Je rajouterai un Assembly que j’appellerais TierseManager.Common, ou je mettrais les contrôles commun, des classes utilitaires, les interfaces ...etc.

Et si tu as plusieurs modules métiers, je mettrais un assembly par module.

Tu as que la couche BAL, je rajouterais une autre couche DAL pour rendre indépendant ta logique métier de l'accès aux données.

[quentin869]

Je te remercie de tes conseils, il y a quelque point que je voudrais encore éclaircir donc pour commencer je n'ai pas de base de données (aucune utilité dans ce projet) donc est ce qu'une couche DAL à son utilité dans ce projet, a moins que je puisse me servir de celle-ci pour faire mes requêtes sur différents site afin d'en extraire le contenu ?

Je partage ton avis de séparer les ViewModel des View mais je n'utiliserais probablement pas silverlight.

Dans mon Assembly TierseManager.Core j'ai plusieurs Class qui on le même but mais dont le protocol n'est pas le même :

./Manager/Site1/Site1Managers.cs // Herite de Site1Protocol.cs
./Manager/Site2/Site2Managers.cs // Herite de Site2Protocol.cs
./Manager/Site3/Site3Managers.cs // Herite de Site3Protocol.cs

./Protocol/Site1/Site1Protocol.cs // Herite de ProtocolBase.cs
./Protocol/Site2/Site2Protocol.cs // Herite de ProtocolBase.cs
./Protocol/Site3/Site3Protocol.cs // Herite de ProtocolBase.cs

./Protocol/ProtocolBase.cs // Classe Abstraite

"Et si tu as plusieurs modules métiers, je mettrais un assembly par module."

Si je comprend bien je pourrais mettre ma classe abstraite dans un nouvel Assembly (TierseManager.Common).

Et faire 3 assembly pour chaque module metiers qui contiendrons chacun un Manager et un Protocol ?

[chamamo]

je n'ai pas de base de données (aucune utilité dans ce projet) donc est ce qu'une couche DAL à son utilité dans ce projet, a moins que je puisse me servir de celle-ci pour faire mes requêtes sur différents site afin d'en extraire le contenu ?

La réponse est oui, peut importe la provenance des données, base de données ou Web, ça reste des données, donc tu peux utiliser le pattern Repository, qui est un point d'entré pour accéder au données qui récupère toutes les données depuis web (avec un filtre si tu vx), un Insert si tu as une entité à poster, un update et Delete (enfin pas toutes mais les opérations que tu utilises)

Si je comprend bien je pourrais mettre ma classe abstraite dans un nouvel Assembly (TierseManager.Common).

Oui.

Et faire 3 assembly pour chaque module metiers qui contiendrons chacun un Manager et un Protocol ?

Je connais pas forcement ton besoin mais à priori oui, le jour par exemple ou tu ajouteras Site4Managers et Site4Protocol tu auras un seul assembly à livrer.

EN espérant que cela répond à tes questions.

[quentin869]

Merci pour ton aide, cela répond exactement à mes interrogation

Concernant celle-ci pourrais-je avoir quelque conseil :

Une autre question qui me trotte dans la tête, actuellement les actions de mes boutons son bindé via RelayCommand dans mon View-Model et ensuite passer dans mon projet TierseManager.Core est-ce la bonne solution ?

[chamamo]

Passées vers TierseManager.Core? Tu peux développer un peu? voir même mettre un peu de code?