Devrais-je séparer les objets métier de l'interface utilisateur dans WPF?

Question

La manière de faire des choses orientée modèle de vue de WPF rend très tentant de n'utiliser que des objets métier dans l'interface utilisateur. Avez-vous vu des problèmes avec cela? Pourquoi ou pourquoi ne feriez-vous pas cela?

Answer 1

Les conseils des équipes produit de Microsoft (par exemple, c’est ce que l’équipe Blend utilise) sont l’architecture Model-View-ViewModel, une variante du modèle MVC populaire. http://blogs.msdn.com est un bon point de départ. /johngossman/archive/2005/10/08/478683.aspx . Le Dr WPF a également publié de bons articles sur ce sujet.

Ils préconisent essentiellement de créer une couche ViewModel qui utilise des objets métier conviviaux pour les liaisons, tels que ObservableCollection et autres.

Par ailleurs, si vous souhaitez éventuellement migrer vers Silverlight 2, vous pouvez conserver les objets métier en dehors de la couche d'interface utilisateur afin de pouvoir échanger la technologie d'interface utilisateur (jusqu'à ce que WPF et Silverlight deviennent compatibles avec le code source).

Answer 2

Je suppose que je le vois sous un jour différent. J'essaie d'éviter autant que possible l'interface utilisateur afin de pouvoir utiliser la présentation d'interface utilisateur dont j'ai besoin (par exemple, Web, WPF, WinForms). Plus il y a de logique métier dans la couche de présentation, plus vous devrez réécrire ultérieurement si vous migrez vers une autre interface utilisateur.

Answer 3

Ce n'est pas un problème d'avoir des objets métier dans l'interface utilisateur, tant que vous ne faites que les les visualiser . En d'autres termes, si vous souhaitez modifier les propriétés d'un élément, en supprimer un ou en créer un nouveau, vous devez envoyer un message au contrôleur, au présentateur ou à tout autre moyen de le faire. et les résultats doivent ensuite être mis à jour dans la vue.

Ce que vous ne devriez pas utiliser, c’est utiliser la méthode ToString de vos objets (ou toute autre méthode ou propriété de vos objets) pour modifier leur apparence dans la vue. Vous devez utiliser DataTemplate pour représenter la vue de vos objets. Si vous avez besoin d'une représentation plus complexe, vous pouvez utiliser un IValueConverter pour changer l'objet en sa représentation visuelle.

Answer 4

N'étant pas un gourou de WPF, je ne peux pas en être sûr, mais la raison habituelle de séparer vos M, V et C est que vous pouvez tester le contrôleur indépendamment de la vue et inversement.

Rien ne vous arrête, bien sûr, mais cela devrait être beaucoup plus testable (c'est-à-dire des tests unitaires) s'il est séparé. Le modèle MVP, qui correspond généralement à celui préconisé par MS, est davantage axé sur le présentateur (c’est-à-dire, votre formulaire WPF), qui a plus de contrôle et qui convient également ....

Answer 5

En fonction de l'architecture de votre application ou de la manière dont vous envisagez de réutiliser vos composants et objets, vous pouvez choisir un certain degré d'indépendance par rapport à l'interface utilisateur (dans ce cas, WPF).

Voici un exemple de mon expérience:

  

J'ai juste un peu travaillé avec WPF, sur   un projet relativement petit, où le   la couche métier était déjà définie,   et nous avions juste besoin de créer un utilisateur   interface. Bien sûr, l'interface   avait défini ses propres règles et objets   qu'il travaillait avec, et parce que   l'application a été définie uniquement pour   UX nous avons choisi de créer notre propre   objets spécifiques, principalement en prolongeant    DependencyObject (principalement pour Données   Liaison ).

     

Certaines personnes peuvent dire que ce n'est pas correct   d'utiliser des objets de dépendance parce qu'ils   ne sont pas sérialisables (en réalité ils   sont - à XAML), ils apportent une   dépendance à WPF (le    System.Windows ), et certains   autres arguments. Également,    DependencyObjects prend en charge autre   des options, telles que propriétés attachées   et propriétés de dépendance . Autres   pourrait utiliser par exemple    INotifyPropertyChanged s'il le permet   est logique, et d'autres pourraient dire que   tous ces modèles n'appartiennent pas à   autre couche que l'interface utilisateur.   (Si vous voulez en savoir plus, il y a   de bonnes WPF liaison de données   articles dans la bibliothèque MSDN,   y compris les meilleures pratiques pour   performances et pour l'interface utilisateur)

C’est un peu dommage que Microsoft ait choisi d’ajouter des bonus à l’espace de noms System.Windows au lieu, par exemple, du System.ComponentModel où à mon avis, ils auraient peut-être été plus utiles (en fournissant tous ces modèles importants non seulement à WPF mais également au .NET Framework).

Bien sûr, ce n’est que le début et beaucoup d’entre nous savons que la chose évoluera dans la bonne direction à la fin. (Avec le risque de sortir du sujet: prenez le framework silverlight 2.0 par exemple. C’était une publication précipitée, certains objets du modèle WPF étant absents et d’autres pas à leur place.)

  

Au final, tout dépend de vous, de votre style de programmation, de vos décisions architecturales et de votre connaissance de la technologie.

     

Si cela vous semble plus naturel de le faire que dans le livre, pensez pourquoi vous devriez et pourquoi vous ne devriez pas avant de prendre une décision!