Besoin de conseils sur la conception des interactions entre les différentes parties de mon application


10

J'essaie de concevoir la ou les classes "principales" d'une application Rich Desktop basée sur NetBeans Platform 7. Cette application consommera des services HTTP et, via un "système push" sur TCP, recevra des messages.

  • Nous sommes 3 développeurs et nous souhaitons développer des modules en parallèle
  • L'application sera en couches (données, affaires, présentation)
  • Nous utiliserons le modèle de présentation afin de séparer les responsabilités
  • Certaines données granulaires (une personne bean par exemple) seront partagées par plusieurs écrans (et éventuellement affichées sur plusieurs écrans en même temps)
  • ...

Nous sommes en mesure de développer des écrans individuels, mais nous ne savons pas exactement comment organiser l'ensemble de l'application et définir le contenu de chaque module.

  1. Alors, avez-vous des conseils (un modèle / une meilleure pratique / un livre / un exemple d'application) pour coordonner / gérer les interactions à l'intérieur de l'application entière?
  2. Des conseils sur la façon de définir le contenu des modules?

Merci!


Petit exemple pour illustrer ce que je veux construire: une application de gestion des utilisateurs Foo

  1. Lancez l'application
  2. A gauche [explorateur] nous avons une liste de plateformes (la liste est stockée dans un fichier local)
  3. En haut, nous avons un bouton pour ajouter une nouvelle plate-forme (également disponible avec un clic droit)
  4. En double-cliquant sur une plate-forme, l'application appelle un service HTTP et récupère une liste complète des utilisateurs. Cette liste est affichée dans [l'éditeur] (dans une JTable)
  5. Un processus d'arrière-plan est lancé: via une connexion TCP, nous recevons des messages
  6. Il est possible d'ajouter un nouvel utilisateur grâce à un bouton dans une barre d'outils

Si l'application est lancée sur un autre PC, et si l'utilisateur est connecté à la même plateforme, sa liste d'utilisateurs sera mise à jour dynamiquement (ajout / suppression / statut: {offline / online}) (grâce aux messages)

À l'avenir, un module de discussion sera fourni.

Ma question est (en d'autres termes): des conseils / meilleures pratiques pour décider du contenu de chaque module? Si le PM (modèle de présentation) est un bon moyen de séparer la vue / l'entreprise et les données et de créer des écrans, quelle est la meilleure façon de lier plusieurs écrans en fonction du PM? Imaginez que nous développions le module de discussion, comment ajouter une entrée "Discuter avec ..." au menu contextuel disponible avec un clic droit sur la liste des utilisateurs?


3
Ce que vous demandez n'est pas clair. Que diriez-vous de fournir un petit exemple pour illustrer votre question?
Robert Harvey,

Grand poste de Geertjan Wielenga. Contient les déclarations des déclarations de Tom Wheeler (membre de l'équipe NetBeans Dream): java.dzone.com/news/how-to-split-into-modules
Destroyica

Réponses:


5

Compte tenu de vos besoins, pour commencer avec les trucs de traitement de base, vous devez utiliser le modèle de commande et plus tard, vous pouvez utiliser des modèles de modèle pour les processeurs de demande. Et ainsi de suite. Il n'y a rien qui s'appelle un modèle Master. S'il y en avait, ils n'auraient plus besoin de nous.

L'idée est d'avoir un design qui vous permettra d'évoluer avec les exigences.

Je commencerais par créer une interface de module de base et donnerais l'interface à tout le monde et à certains utilitaires qui l'entourent. Laissez chacun implémenter ses propres modules basés sur le module de base.


3

Je pense que vous regardez un modèle MVC assez classique soutenu par des services (RESTful je suppose). La clé sera de séparer le (s) service (s) de l'interface utilisateur. Ce n'est pas parce que vous introduisez une interface utilisateur alternative, mais parce que vous donne une clarté sur ce que devrait être votre interface de service.

Donc, lorsque vous pensez au getPeopleservice, assurez-vous de penser à la façon dont une interface utilisateur secondaire (non Swing) interagirait avec le service. Si vous gardez cela à l'esprit, vous trouverez une solution assez flexible / découplée.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.