2016-04-29 1 views
0

Je suis en train de tenter de modifier un projet Windows Forms existant pour mieux respecter les principes SOLID. Actuellement, il existe une classe principale qui initialise le formulaire et toute la logique est ensuite traitée dans une classe logique.Couplage de classe C# avec Windows Forms

Ceci crée un couplage élevé et n'est pas non testable car tout le locic change des choses sur le formulaire principal. Par exemple, j'ai un bouton pour actualiser une grille, cela appelle la classe logique pour construire les données, puis cela rafraîchit la grille. Voici un petit exemple de ce à quoi il ressemble actuellement.

public partial class XpressReports : Form 
{ 
    private void refresh_ItemClick(object sender, DevExpress.XtraBars.ItemClickEventArgs e) 
    { 
     try 
     { 
      Globals.DataLogic.RefreshData(); 
     } 
     catch (Exception ex) 
     { 
      MessageBox.Show(this, ex.Message); 
     } 
    } 
} 

public class DataLogic 
{ 
    public void RefreshData() 
    { 
     dataset selectedTableList; 

     selectedTableList = GetNonRefreshFlagColumnIdList(); 

     dataGridView.Columns.Clear(); 
     dataGridControl.DataSource = null; 
     dataGridControl.DataSource = dataViewData.Tables[0]; 
    } 
} 

Je ne suis pas sûr de l'approche idéale pour quelque chose comme ça. Je pourrais créer une nouvelle méthode mettre à jour la source de données dans la classe de formulaire principale, mais il y aurait encore beaucoup de retour et de retour entre les deux. Quelle est la meilleure façon de séparer ce genre de chose?

+2

Vous avez la bonne idée. Ce n'est pas aussi couplé que vous pourriez le penser. L'idée derrière la méthodologie que vous utilisez est que si nécessaire, vous pouvez échanger l'interface utilisateur et avoir toujours la même logique en arrière-plan. La seule chose que je recommanderais pour faire un couplage un peu plus lâche serait comme vous l'avez dit, avez un de vos contrôles mettre à jour la source sur le côté de l'interface utilisateur. Par exemple, RefreshData peut renvoyer l'ensemble de données au lieu de le définir dans cette méthode. Et votre méthode de formulaire pourrait définir la source de données à partir de cela. De cette façon, votre logique renvoie toujours un jeu de données et ne se soucie pas de l'interface utilisateur. – oppassum

Répondre

1

Le plus clair que j'ai vu jusqu'à présent dans les formulaires Windows est l'utilisation d'un modèle Presente.

Vous pouvez appeler directement votre présentateur à partir du formulaire ou des événements de déclenchement auxquels le presereur est abonné.

Le présentateur conserve une référence à la vue (formulaire) et appelle les méthodes appropriées. Utilisez une interface pour les méthodes de vue afin de découpler votre présentateur de votre formulaire actuel.

Quelque chose comme le pseudo-code suivant:

public interface IView 
{ 
    event EventHandler Initialise; 
    void SetData(MyData data) 
} 

public class Presenter 
{ 
    .... 

    public Presenter(IView view) 
    { 
     _view = view; 
     _view.Initialise += OnViewInitialise; 
    } 

    public void OnViewInitialise() 
    { 
      var data = _repository.GetData(); 
      _view.SetData(data); 
    } 
}