Approche de développement: interface utilisateur entrée ou modèle de domaine sorti?

Bien que je n'aie jamais rien livré en utilisant Smalltalk, mon bref temps à jouer avec lui a définitivement laissé sa marque. La seule façon de décrire l'expérience est MVC telle qu'elle était censée être. Essentiellement, tout le gros du travail pour votre application se fait dans les objets métier (ou le modèle de domaine si vous êtes si enclin). Les contrôles standard sont liés aux objets métier d'une manière ou d'une autre. Par exemple, une zone de texte est mappée au champ d'un objet (le champ lui-même est un objet, donc c'est facile à faire). Un bouton serait mappé à une méthode. Tout cela se fait avec une API très simple et naturelle. Nous n'avons pas à penser à lier des objets, etc. Cela fonctionne simplement.

Pourtant, dans de nombreux langages et API plus récents, vous êtes obligé de penser de l'extérieur. D'abord avec C ++ et MFC, et maintenant avec C # et WPF, Microsoft a accroché son monde de développeurs aux constructeurs d'interfaces graphiques où vous créez votre application en implémentant des gestionnaires d'événements . Le développement Java Swing n'est pas si différent, seulement vous écrivez le code pour instancier vous-même les contrôles du formulaire. Pour certains projets, il peut même ne jamais y avoir de modèle de domaine - juste des gestionnaires d'événements. J'ai été dans et autour de ce modèle pendant la majeure partie de ma carrière.

Chaque façon vous oblige à penser différemment. Avec l'approche Smalltalk, votre domaine est intelligent tandis que votre interface graphique est stupide. Avec l'approche VisualStudio par défaut, votre interface graphique est intelligente tandis que votre modèle de domaine (s'il existe) est plutôt anémique.

De nombreux développeurs avec lesquels je travaille voient de la valeur dans l'approche Smalltalk et tentent d'intégrer cette approche dans l'environnement VisualStudio. WPF a quelques fonctionnalités de liaison dynamique qui le rendent possible; mais il y a des limites. Inévitablement, du code appartenant au modèle de domaine se retrouve dans les classes GUI.

Alors, comment concevez-vous / développez-vous votre code? Pourquoi?

• GUI d'abord. L'interaction avec l'utilisateur est primordiale.
• Domaine d'abord. Je dois m'assurer que le système est correct avant de mettre une interface utilisateur dessus.

Il y a des avantages et des inconvénients pour l'une ou l'autre approche. Le modèle de domaine s'y adapte avec des cathédrales de cristal et une tarte dans le ciel. GUI s'intègre là avec rapide et sale (parfois vraiment sale).

Et pour un bonus supplémentaire: comment vous assurez-vous que le code est maintenable?

Ni

Au fil des années, j'ai développé des logiciels, je me suis retrouvé à pratiquer une première méthodologie car il y a toujours un "terrain d'entente" à prendre en considération. Mettez une interface entre le code de l'interface utilisateur et le code d'entreprise, et convenez de ce dont l'interface utilisateur a besoin pour le moment à partir du domaine.

Permettez-moi de faire un chiffre pour rendre ce concept clair:

  +------+
  |  UI  | <- Think about how to make an effective user interface
  +------+
      |
      |
 +----------+
 | Contract | <--- This part over here is really REALLY important, man!
 +----------+
      |
      |
+--------------+
| Domain model | <- Think about what the user needs
+--------------+ 

De cette façon, vous pouvez travailler de manière itérative sur l'interface utilisateur et le modèle de domaine séparément si le juste milieu indique clairement quelles données l'interface utilisateur peut recevoir.

La raison pour laquelle je vois pourquoi certains projets deviennent irréalisables est que l'interface entre les données et la présentation a été précipitée ou inexistante (avec un code de traitement direct des données dans l'interface utilisateur). J'ai vu tellement de projets où le code de la base de données résidait dans le code du formulaire que j'ai perdu confiance en l'humanité. Seuls les quelques projets que j'ai vus qui ont ce juste milieu rigide restaurent cette foi perdue.

Peu importe de quelle extrémité vous commencez en premier ... ce qui compte, c'est que vous ayez cette séparation claire des préoccupations en place. Ce contrat au milieu définit à peu près l'application ou le système à portée de main. Pensez à celui-ci avant d'aller de bas en haut ou de haut en bas .

Domaine d'abord. Je dois m'assurer que le système est correct avant de mettre une interface utilisateur dessus.

Rien d'autre ne peut fonctionner - sauf dans des cas simples.

Commencer à partir de l'interface utilisateur conduit souvent à un logiciel fragile et buggé qui peut sembler amusant, mais a souvent de graves problèmes dans le modèle.

Il n'est pas acquis que l'interface utilisateur est d'abord vouée à l'échec - si le modèle est assez simple, l'interface utilisateur peut être construite en premier avec la certitude que le modèle fonctionnera bien à la fin.

Dans tous les cas où le modèle ne peut pas être facilement imaginé, il doit être construit en premier.

Le pire des cas est celui où certains programmeurs pensent pouvoir imaginer le modèle. Ils peuvent avoir omis des détails importants, des cas spéciaux, des exceptions ou des considérations de performances. Étant donné que l'interface graphique a déjà été construite et que de nombreuses considérations ont été omises, le modèle est terrible.

Cela dépend vraiment de l'application en cours.

Si vous construisez une application client / serveur fermée, l'une ou l'autre approche suffirait; car vous allez manipuler le back-end pour l'adapter aux besoins du front-end.

Si vous créez une application client / serveur ouverte où un service Web potentiel sera exposé pour être utilisé par vos clients, il est essentiel de savoir comment ce service peut être utilisé par un client pour développer un frontal.

Souvent ces derniers temps en ce qui concerne une poussée de petits cycles itératifs en développement (Scrum, Kanban, etc ...) le front end et le back end se font en parallèle. Il s'agit de fournir ce dont vous avez besoin pour cette itération donnée; sans tenir compte de la construction au cas où nous en aurions besoin . Dans une approche parallèle, les deux extrémités restent beaucoup plus proches tout au long du développement, ce qui peut atténuer la nécessité d'un changement continu lorsque le front-end et le back-end fusionnent. C'est mon approche préférée lorsque cela est possible.

Vous avez mentionné...

... WPF a quelques fonctionnalités de liaison dynamique qui le rendent possible; mais il y a des limites. Inévitablement, du code appartenant au modèle de domaine se retrouve dans les classes GUI ...

Vous ne savez pas ce que vous entendez par certains ? WPF et SL sont tous deux connus pour leur fonctionnalité de liaison. C'est sans fin. Si vous êtes obligé de placer du code dans votre vue dans une application WPF basée sur MVVM, quelque chose doit être résolu. Les comportements associés sont un moyen d'implémenter un comportement sans lier les événements dans la vue, ainsi que de nombreuses autres approches pour garantir que votre vue reste propre.

Le front-end d'une position d'interaction avec l'utilisateur ne devrait avoir rien à voir avec l'implémentation du back-end. La tâche principale du back-end pour un frontal est de fournir des données via des données de traitement ou d'autres moyens. Cela rejoint le type d'application en cours de développement.

S'assurer que le code source est maintenable est vraiment une question entièrement différente en soi. À un niveau élevé, il concerne les meilleures pratiques de codage ainsi que les modèles, architectures et technologies éprouvés suivants.

Je préfère d'abord concevoir l'interface utilisateur de base (même si ce n'est que sur papier), avec la contribution du client. Le client peut ne pas vraiment savoir ce qu'il veut tant qu'il ne l'a pas vu. Vous ne pouvez pas toujours faire confiance à ce que le client vous dit. Vous pourriez investir des semaines à écrire un modèle de domaine robuste uniquement pour découvrir qu'il ne correspond pas à ce que le client comprend après avoir commencé à voir les prototypes d'interface utilisateur.

Nous essayons de piloter notre logiciel avec des tests automatisés. Les tests automatisés de l'interface utilisateur prennent beaucoup de temps. Les scripts pour vérifier certaines valeurs sur une console sont plus faciles.

Dans cet esprit, nous veillons à garder la logique métier distincte de l'interface utilisateur.

Je me souviens même d'avoir eu un développeur principal qui m'a crié que l'architecture Document / View était considérée comme obsolète lorsque j'ai suggéré que nous devions arrêter de lier tout notre code d'entreprise avec l'interface utilisateur (et nous utilisions win32 en C ++ à l'époque, donc cette programmation glisser-déposer ce n'était même pas notre problème). J'étais simplement abasourdi.

IMNSHO, il n'y a tout simplement aucune excuse pour ne pas avoir au moins une couche entreprise vs interface utilisateur. Si votre produit fait quelque chose de légèrement intéressant, il est absolument nécessaire que cette séparation permette la réutilisation du code.

En tant que développeur C #, je ne pense vraiment pas que vous êtes obligé de travailler à l'extérieur. En fait, je préfère d'abord faire un modèle de domaine.

Pour WPF, le seul inconvénient du modèle que j'ai décrit, c'est que vous devez parfois arbitrer entre votre interface utilisateur et votre modèle de domaine. Pourtant, bien que cela signifie parfois plus de travail, cela signifie également un code plus propre.

Certainement, le domaine d'abord!

La beauté de Smalltalk était que vous pouviez très facilement "piloter" un modèle de domaine de nombreuses manières, y compris en le "imprimant" à partir d'un espace de travail ou d'un inspecteur. Ce n'est que lorsque vous avez été sûr que votre domaine fonctionnait comme souhaité que vous avez osé vous concentrer sur la création de l'interface graphique parfaite.

Cela ne veut pas dire que Smalltalkers n'a pas fonctionné sur les deux simultanément, mais lorsque votre interface graphique n'a pas réussi à implémenter la logique métier, vous avez généralement corrigé le modèle de domaine en premier, plutôt que de mettre des cas spéciaux dans votre interface graphique.