Architecture 3 tiers et Winforms : conseils

Bonsoir à tous,
Je développe depuis quelques temps en C# des applis Winforms, avec une base SQL Server. Elles deviennent de plus en plus complexes et c'est compliqué de les faire évoluer et de les maintenir évidemment. J'ai donc décidé d'adopter une certaine discipline.
J'ai déjà parcouru beaucoup d'articles et je vois globalement ce que je dois faire, mais j'ai besoin d'un petit coup de main sur quelques points bien précis.
J'adopte une structure 3 couches avec un peu d'injection de dépendance, en essayant de respecter un principe SOLID, etc...
Pour prendre un exemple simple, considérons que mon appli gère des utilisateurs.
J'ai donc le Form pour l'IUI, une classe User pour l'utilisateur, une classe UserService avec son interface IUserService pour le Business et une classe UserRepository avec une interface IUserRepository pour la gestion de la BDD.
Question 1
J'instancie IUserService dans le Form, ca c'est OK. Mais qui gère User(en gros qui l'instancie et l'utilise), le Form ou UserService?
Ensuite, par exemple j'obtiens une liste d'utilisateurs pour mettre dans une ListBox avec une méthode GetAllUsers de UserService.
Maintenant je voudrais mettre une méthode UpdatePhoneNumber pour mettre à jour dans la base un utilisateur sélectionné dans cette liste.
Question 2
Mais dans quelle classe je dois mettre cette méthode, User ou UserService?
Et enfin ma dernière question qui est un peu dépendante des autres.
Question 3
Comment je communique entre l'UI et le Business? J'envoie un User en ref dans UserService, je le triture et je le récupère ensuite dans l'UI ou alors je gère tout le temps User dans UserService et je mets à jour les champs du Form avec les propriétés de User. Ce qui m'embête dans ce dernier cas, c'est que dans mon esprit, UserService est destiné à traiter des opérations sur l'ensemble des utilisateurs (en gros quand je n'ai pas d'Id User défini) et là elle traiterait également un User.

J'espère avoir été clair et je remercie par avance pour vos conseils d'experts.

Bonjour,

Pour moi, il te manque une couche et tu veux faire communiquer des couches qui ne sont pas sensé le faire.
C'est pour ça que tu galères.

En gros :
- une couche IHM qui connaît la couche Service
- une couche Service qui connaît la couche Repository et la couche qu'il te manques (que j'appellerai BusinessObject)
- une couche Repository qui gère l'accès à la source de données
- une couche BusinessObject qui gère quelques règle de validation métier (d'où son nom) notamment pour l'insertion

Pour entrer plus dans les détails :
La couche IHM communique uniquement avec la couche Service au moyen de DTO.
Ton IHM instancie donc un IUserService et potentiellement des DTO en entrée.
La couche Service fournit des méthodes comme GetAllUsers ou UpdatePhoneNumber.
Chacune de ces méthodes prendra donc un DTO en entrée et/ou un DTO en sortie.
Au sein de ces méthodes, tu fait appel à la Repository pour aller chercher tes données ou les modifier.
La couche Repository est la seule à communiquer avec la source de données.
En fonction du besoin la méthode de service instanciera un objet métier et y jouera les règle de validations.
Une fois l'objet métier conforme, la méthode de service rend le résultat sous forme de DTO pour GetAllUsers ou d'un booleén pour UpdatePhoneNumber.
L'objet métier n'est jamais connu de l'IHM, il est connu uniquement de la couche service.