Langage C#
  1. Langage C#
  3. WPF MVVM Code derrière les meilleures pratiques
Intereting Posts
Liaison de SolidColorBrush avec l’arrière-plan ControlTemplate Comment masquer mon application SmartDevice au démarrage? c # MSOffice Interop Word ne tuera pas winword.exe Analyse descendante implémenter en c # Hériter d’un ‘formulaire’ qui a des parameters Exclure / Supprimer une valeur de MVC 5.1 EnumDropDownListFor AAAAMMJJ Format de date Expression régulière pour valider une date dans C # .net Méthodes de dénomination enregistrées dans les événements Comment additionner des colonnes dans un dataTable? Comment utiliser la sérialisation ou la désérialisation personnalisée dans WCF pour forcer une nouvelle instance sur chaque propriété d’un contact de données? C # – Recherche de pics dans une largeur donnée via un ajustement quadratique Obtenir les codes de sortie de l’application WindowsForms dans la fenêtre de commande ExternalLoginConfirmation renvoie la valeur null après une connexion réussie avec facebook Utilisation d’un gestionnaire HTTP dans ASP.NET pour générer une image à afficher dans un courrier électronique Thread.sleep vs Monitor.Wait vs RegisteredWaitHandle?

WPF MVVM Code derrière les meilleures pratiques

Je suis un étudiant qui apprend C # avec WPF en utilisant le modèle MVVM. Récemment, j’ai travaillé sur un [art de mon application (un écran de démarrage personnalisé) qui ne devrait pas être fermé quand je ne le souhaite pas. J’ai cherché sur le Web un bon moyen de le faire sans code-behind. Malheureusement, après des jours, je n’ai toujours pas trouvé de solution satisfaisante. Ensuite, j’ai réfléchi à une façon de le faire moi-même, avec l’aide d’une seule ligne de code dans le constructeur de mon sharepoint vue. Cela rend toujours mon code testable et le dissocie de la vue. La question est de savoir s’il existe une meilleure façon de faire ce que j’essaie de faire:

Mon interface pour mon ViewModel 

public interface IPreventCloseViewModel { bool PreventClose { get; set; } }

L’extension pour la vue 

 public static class PreventCloseViewModelExtension { ///  /// Use this extension method in the constructor of the view. ///  ///  public static void PreventCloseViewModel(this Window element) { var dataContext = element.DataContext as IDisposable; if (dataContext is IPreventCloseViewModel) { element.Closing += delegate(object sender, CancelEventArgs args) { if (dataContext is IPreventCloseViewModel) { args.Cancel = (dataContext as IPreventCloseViewModel).PreventClose; } }; } } }

Le code de la vue 

 public partial class SplashScreen { public SplashScreen() { InitializeComponent(); this.PreventCloseViewModel(); } }

MVVM ne signifie pas que vous ne pouvez pas utiliser Code-Behind.

MVVM signifie que votre logique d’application ne doit pas être liée à des éléments d’interface utilisateur.

Vous pouvez parfaitement gérer les événements dans le code derrière (comme Window.Closing ) et “envoyer des messages” ou exécuter des méthodes dans ViewModel pour réagir à cela.

Ici, vous ne détruisez pas MVVM en plaçant le gestionnaire d’événements dans le code derrière. Vous rompriez MVVM si vous plaçiez la logique qui détermine si l’application peut être fermée dans le code derrière. C’est une responsabilité de la logique d’application, et la logique d’application réside dans ViewModels, pas dans Views.

J’ai généralement une classe Shell générique qui sous-classe Window et fait quelque chose comme: 

 public Shell() { InitializeComponent(); this.Closing += (s,e) => { var canClose = Content as ICanClose; if (canClose != null) e.Cancel = !canClose.CanClose; } }

De cette manière, le type de modèle de vue que vous avez inséré n’a pas d’importance, s’il implémente l’interface à prendre en compte.

Il ne faut pas voir grand-chose à externaliser la logique, et c’est très bien en termes de modèle MVVM.