[C# 2.0] Validation d'architecture (multithreading, communication et . . . Tests ! )

Version imprimable

09/07/2008, 15h01
ElTchoupi

[C# 2.0] Validation d'architecture (multithreading, communication et . . . Tests ! )

Bonjour,

Je me jette enfin dans un projet qui me tiens à coeur et aurais besoin d'un petit coup de main pour vérifier que je ne m'oriente pas dans une mauvaise direction (je suis assez novice en .Net !)

Je prépare une application qui fais beaucoup de traitement sur des données loadées à partir de fichiers et qui doit pouvoir afficher les résultats ou les données elles-mêmes sur un client.
Pour l'instant, mon client est une application console, mais va ensuite etre une WinForm pour afficher des courbes...
Je prévois de valider la plupart du projet par des tests avec utilisation de Mocks.

Je parle beaucoup en mode client/serveur du fait de mes antécédants en entreprises, mais mon "moteur de traitement" n'aura toujours qu'un "client" à la fois, il aura par contre parfois beaucoup de traitement à faire (à priori, par la lib C++ BOOST), potentiellement longs et donc asynchrones.

Ma vue de la chose:

* Un moteur de traitement dans une assembly (en dll)
- Un thread principal (lancé par le client) qui gère les autres
- Un thread de load des données (à partir des fichiers) dans les DataSets
- Un thread de validation des données des DataSet (au fil de l'eau, après les loads)
- Un thread de gestion des travaux de traitement
- Un ensemble de threads de traitement des données par appel à Boost (C++)
* Les clients (console ou WinForm) en EXE avec une ref sur le moteur

La communication se ferait par Requetes du client au Serveur pour la majorité mais aussi avec des Events pour les fins de traitement asynchrones...

D'après ce que j'ai pu voir (toujours en entreprise), les tests (en particulier avec des Mocks) sont largement facilités par l'utilisation d'interfaces pour les types de données qui passent entre les différentes couches.
J'en viens donc à penser à "normaliser" mes types de données de communication entre le moteur de data et le client (du type IRequest/Ireply).
N'ayant jamais fais de projet de ce type, je me demande s'il est répandu d'avoir des types spéciaux de données pour les échanges DLL/EXE et surtout si cela ne va pas allourdir inutilement le tout...

Avez-vous des expériences sur ce type d'architecture ? Si oui, avez-vous des recommandations ? Est-ce que je parts dans la bonne direction ou est-ce que je devrait repenser certains morceaux ?

Merci d'avance de votre aide et de votre retour d'experience !

--
ElTchoupi
09/07/2008, 15h05
tomlev

pour la communication, je te conseille de t'orienter vers WCF
pour le reste, euh... j'ai pas compris grand chose, ça reste très abstrait...
09/07/2008, 16h19
ElTchoupi

Bonjour tomlev,

Merci pour ta réponse rapide !

Citation:

Envoyé par tomlev

pour la communication, je te conseille de t'orienter vers WCF

Pourquoi utiliser WCF ? Est-ce que la simple communication Dll/Exe ne suffit pas ? (J'avoue que rester en 2.0 m'arrangerait...)

Citation:

Envoyé par tomlev

pour le reste, euh... j'ai pas compris grand chose, ça reste très abstrait...

Mon principal questionnement est sur un moyen simple mais sûr de faire travailler differents thread sur des DataTables (un pour le Load, un pour la validation, plusieurs pour la modification par traitement mathématiques..) et pouvoir informer un client de ce qui se passe en interne...
09/07/2008, 17h23
tomlev

Citation:

Envoyé par ElTchoupi

Pourquoi utiliser WCF ? Est-ce que la simple communication Dll/Exe ne suffit pas ? (J'avoue que rester en 2.0 m'arrangerait...)

Je ne vois pas ce que tu appelles la "simple communication Dll/Exe"... tu cherches à communiquer en réseau entre un serveur et un client, non ? ou alors j'ai rien compris...
Si tu veux rester en 2.0, tu peux toujours t'orienter vers les webservices ou le remoting

Citation:

Envoyé par ElTchoupi

Mon principal questionnement est sur un moyen simple mais sûr de faire travailler differents thread sur des DataTables (un pour le Load, un pour la validation, plusieurs pour la modification par traitement mathématiques..) et pouvoir informer un client de ce qui se passe en interne...

D'après la doc de la classe DataTable :

Citation:

Envoyé par MSDN

Sécurité des threads
Ce type est sécurisé pour les opérations de lecture multithread. Vous devez synchroniser les opérations d'écriture.

Donc a priori un seul thread peut travailler en écriture sur un datatable donné...
09/07/2008, 22h46
ElTchoupi

Re-Bonjour,

Je me rends compte que je me suis bien mal exprimé..
Mon application ne sera, in fine, qu'un exe avec un certain nombre de dll...

Je parle de communication "client/serveur" parce que je ne veut pas que mon EXE ne s'occupe d'autre chose que de l'affichage: tout ce qui concerne le load, la validation puis les modifications des données sera fait par mon "DataEngine"; du coup, j'ai tendance à raccourcir cette architecture en un ensemble de Dll "core" qui serve de serveur et un EXE de client.

L'idée était ensuite de "normaliser" tous les appels de fonction de mon Core pour que les données échangées implémentent un IRequest ou un IReply selon le cas, afin de faciliter l'implémentation des "clients" EXE: j'aurais en tout 2 client WinForms, 1 client Console et un ensemble de tests à mettre en place... et il me semblais que passer par ce type de contrat m'assurait une certaine cohérence globale et donc une implémentation plus rapide pour chaque client.
Mais j'ai par contre la crainte que cela n'alourdisse globalement l'application...

En ce qui concerne les DataTables et leurs manipulation par des threads différents, j'avais effectivement lu cette obligation de gérer soi-même la sécurisation de l'écriture; mais, travaillant par colonnes, je me demandais s'il est envisageable de verrouiller la seule colonne susceptible d'être modifiée ou est-ce que toute la table doit l'être ? (J'avais prévu de ne pas laisser les Tables en cours de Load puis de validation, accessibles au client afin d'être sur de ne pas avoir de problème de ce coté).
A préciser (cela a peut-être son importance dans ce genre de cas), que toutes mes données sont chargées à partir de fichier plats (principalement Excel et csv), et qu'aucun lien avec une "vraie" BDD n'est prévue...

Merci pour ta patience et pour ton aide !

--
ElTchoupi
09/07/2008, 22h58
tomlev

Je pense que tu te compliques la vie inutilement...
Il suffit de faire des DLL qui font les traitements et de les référencer à partir de ton exe, que ce soit une appli console ou Windows Forms. Je ne vois pas trop l'utilité de créer des interfaces dans ce cas, il s'agit juste d'utiliser les classes définies dans les DLL.

Si certaines de tes DLL doivent être en C++, je te conseille de lire ces tutos pour gérer l'interopérabilité entre le code natif et le code managé (.NET) :
http://nico-pyright.developpez.com/t...c2005/interop/
http://nico-pyright.developpez.com/t...2005/interop2/

Enfin, je ne pense pas qu'il soit possible de verrouiller une seule colonne dans un datatable (l'unité de traitement est plutôt la ligne)
09/07/2008, 23h38
ElTchoupi

OK pour l'utilisation des DLL en "direct", je me permet de laisser le thread encore un peu "non-résolu" au cas ou quelqu'un aurait une remarque à faire en ce qui concerne les Tests Mockés (il semble que l'utilisation d'interfaces facilite, par la suite, beaucoup la chose...?) .

Merci aussi pour les liens: je n'en suis pas encore là, mais c'est exactement ce dont je vais avoir besoin !

Enfin merci pour ton temps, tout simplement !

--
ElTchoupi
Qui n'a pas non plus trouvé où mettre sa signature...permanente !
10/07/2008, 00h28
tomlev

Effectivement, ça peut être pas mal pour les tests d'établir un contrat d'interface entre ton exe et tes DLL, histoire de pouvoir avancer sur l'UI sans que toutes les DLL soient implémentées... enfin, à mon avis c'est surtout utile si vous êtes plusieurs à développer chacun une partie, ou encore si tu veux avoir différentes implémentations pour tes DLL (par exemple, une DLL "loader" qui charge des fichiers XML, une autre qui charge des fichiers plats, etc...)
10/07/2008, 09h16
ElTchoupi

Citation:

Envoyé par tomlev

Effectivement, ça peut être pas mal pour les tests d'établir un contrat d'interface entre ton exe et tes DLL, histoire de pouvoir avancer sur l'UI sans que toutes les DLL soient implémentées... enfin, à mon avis c'est surtout utile si vous êtes plusieurs à développer chacun une partie, ou encore si tu veux avoir différentes implémentations pour tes DLL (par exemple, une DLL "loader" qui charge des fichiers XML, une autre qui charge des fichiers plats, etc...)

C'est effectivement ce vers quoi je m'oriente: mes classes de Load aussi bien que celles de validation de Data ou celles qui gèrent les actions que je peux demander au DataEngine sont loadées à la demande, avec un peu d'introspection, en fonction de leurs noms: pas besoin d'ajouter une prise en compte en dur dans mon code pour gérer les XML: je n'aurais qu'à rajouter une classe XMLfileLoader dans le bon namespace pour que ça tourne tout seul ;)