Tous les contrôles d'un logiciel complexe doivent-ils hériter d'une interface auto-écrite?

Question

Est-ce une bonne idée de créer une interface pour le plus grand nombre de contrôles devant être utilisés dans un logiciel complexe (wirtten avec C#/wpf)? Actuellement, nous avons le problème, que nous utilisons des contrôles de Microsoft et de certaines sociétés tierces. Notre problème est que, si nous voulons changer certains composants tiers, nous ne voulons pas changer le logiciel de hurlement, parce que nous faisons beaucoup de personnalisation pour notre client.

Donc, c'est une bonne idée de créer une classe abstraite pour chaque contrôle que nous utilisons, et d'utiliser uniquement le membre fourni par la classe/interface abstraite?

Peut-être que c'est une mauvaise solution pour certaines raisons, et je ne comprends pas.

Merci!

Answer 1

Ceci est une question très profonde mais je vais essayer de vous donner une réponse.

Je commencerais par dire qu'il est très bon de séparer la logique de présentation des contrôles de l'interface utilisateur. Généralement, vous devriez jeter un coup d'œil à un modèle de conception dérivé de MVP ou utiliser le modèle de tendance actuel, le «modèle de présentation» inventé par Martin Fowler.

Je recommande fortement de lire toutes les informations sur la conception de logiciels et les meilleures pratiques. D'après mon expérience, le meilleur gain d'une séparation entre l'interface utilisateur et la logique de présentation ne change pas la technologie UI, mais vous donne la liberté de tester très facilement votre logique de présentation. Dans toute ma carrière, je ne suis jamais passé à un autre fournisseur de contrôles d'interface utilisateur. Donc, gardez à l'esprit que la TESTABILITÉ ne change pas la technologie de l'interface utilisateur. Par exemple, dans WPF (vous avez dit que vous utilisez WPF), il y a déjà un motif logique de présentation utilisé => le MVVM qui n'est pas quelque chose de fantaisiste mais l'ancien modèle de présentation dans un vêtement rebrandé. En relation avec la façon dont vous pensez de votre problème ... l'approche que vous décrivez est plus liée au modèle "Model-View-Presenter", plus exactement le sous-modèle de vue passive dans lequel les contrôles sont extraits de la présentation logique en utilisant des interfaces. L'état est présent dans l'interface utilisateur et la logique dans le présentateur. Ceci est contraire au modèle de présentation dans lequel l'état est présent et la logique également présente.

Je pense que vous ne devriez pas faire un cocktail de modèles de présentation dans votre application et mon conseil serait: Laissez MVVM comme motif de base et essayez de l'utiliser correctement. La testabilité sera améliorée par ce modèle et je ne pense pas que vous aurez jamais besoin de changer la technologie de l'interface utilisateur dans votre cas. Mais même si vous allez le changer, si vous avez codé corectly sur MVVM, le changement sera faisable. Avec MWWM, voulez-vous dire MVVM?