Meilleure Architecture de Tableau De Bord

Tout d'abord, il existe de nombreux frameworks frontaux pour vous aider à démarrer. Certains des plus populaires incluent:

• épine Dorsale
• Javascript MVC
• Sproutcore

Un peu de recherche Google peut yeild avantages et inconvénients de chacun et je pondérerais vos options en conséquence.

Cela étant dit, le problème de base que vous avez posé semble en fait similaire au nôtre. En fin de compte, nous avons construit quelque chose d'un peu différent dans la maison. Beaucoup parmi les frameworks disponibles, ils sont optimisés pour afficher une "vue" canonique singulière basée sur un modèle reflété par la base de données et un contrôleur pour gérer les petits changements. Un tableau de bord a, en substance, une variété de modules différents qui doivent faire leurs propres choses indépendantes comme vous l'avez mentionné dans votre question. En raison du nombre élevé de modules indépendants, j'ai le sentiment que vous pourriez ressentir des douleurs dans certains cadres énumérés ci-dessus.

Je ne peux pas vous dire exactement comment implémenter un tel module architecture, mais voici quelques règles empiriques que nous avons utilisées lors de la conception de la nôtre:

Conception du module:

• Basé sur des modules. (Module de connexion, module de carte, chaque Dashlet peut être un module, etc.)
• Les modules doivent avoir un Modèle, ne peuvent pas avoir plus d'une Collection (qui est-un Modèle) et peuvent avoir une ou plusieurs vues.
• Un module peut être utilisé à plusieurs endroits et pages. Le modèle singulier devrait rester le même, mais les vues sont probables différent.

Rendu:

• Presque tout le HTML sur la page est écrit et mis à jour par des modules javascript. Les fichiers de modèle sont presque vides à l'exception des en-têtes et des échafaudages de base.
• Tous les modules rendent leur moi HTML complet et se remplacent dans le DOM. Le module doit avoir une représentation HTML statique complète prête à l'emploi avant d'être insérée dans le DOM. Cela signifie que les fonctions de rendu utilisent ".remplaceavec()" au lieu de ".annexer()".
• Si le simple remplacement HTML n'est pas une option (c'est-à-dire qu'il doit être animé), une fonction de transition doit être définie en détaillant comment passer d'un état rendu à un autre.
• Parce que le rendu est coûteux, les vues par défaut ne s'actualisent pas automatiquement sur toutes les modifications de modèle. Le re-déchirage se produit uniquement par le biais d'événements. _render() est en fait une méthode interne.

Orthogonalité:

• Un seul répartiteur d'événements inter-modules sur le contrôleur de page gère tous les effets croisés entre les modules.
• Les modules ne doivent jamais "atteindre l'extérieur" de leur propre contexte DOM. Si un événement dans un module en affecte un autre, il doit passer par le répartiteur du contrôleur de page.
• Chaque module aussi orthogonal que possible. Ils dépendent les uns des autres aussi peu que possible.
• Chaque module dans son propre fichier.

Connexion au backend:

• Tous les modules utilisent le même adaptateur backend global. Les modules ne parlent jamais au backend par eux-mêmes. Cela rend votre back-end frontal agnostique.

Récursive:

• Les modules sont généralement inclus dans d'autres modules.
• Les modules restituent récursivement.

Testable:

• Parce que les modules rendent du HTML statique, ils peuvent être testés de manière prévisible.
• Les modules doivent être testables.
  • Entrée standard -> Module -> Sortie HTML statique prévisible.
  • Événements standard - > Module - > Prévisible sortie HTML statique.

Si quelqu'un connaît d'autres frameworks dans ce sens, veuillez partager!

Notre application web est basée exactement sur cette architecture et en production depuis la fin de l'année dernière. Vous pouvez le voir à http://beebole.com

Nous avons juste optimisé les appels vers notre propre serveur. Il y a un seul appel pour obtenir les données communes nécessaires à la plupart des widgets, chaque fois qu'un écran est chargé.

Ensuite, si un widget a besoin de données supplémentaires, il effectue lui-même un appel à notre serveur. Les widgets externes appellent aussi leurs propres données, mais vers un autre serveur.

Je déconseillerais d'utiliser un framework Web personnalisé lorsqu'il y en a autant de gratuits disponibles.

Comme mentionné dans une autre réponse, les frameworks de style MVC traditionnels ne correspondent pas vraiment bien au style d'interface utilisateur souhaité par votre "tableau de bord". Ils sont mieux utilisés pour créer des sites Web statiques basés sur des données récupérées ailleurs. Ils ne gèrent pas bien l'interaction utilisateur et vous devez généralement rouler votre propre AJAX pour faire quelque chose d'utile sans demande de page.

Un meilleur la race de frameworks web à regarder est le Web 2.0 fraemworks, également connu sous le nom de frameworks qui vous aident à créer des applications Web . Il est important de comprendre la différence entre le site Web et les applications Web. Ils sont généralement différenciés par le fait que ce dernier est interactif et que le premier est principalement statique. Les sites Web qui ont également des composants interactifs sont toujours des sites Web. Une bonne façon d'y penser est de vous demander "Est-ce que cela ressemble à une application de bureau?".

Pour le web développement d'applications dans le domaine Java (JVM), j'utiliserais Vaadin. Il vous permet d'écrire du code Java similaire à la programmation Swing, avec des méthodes basées sur les événements. Vous pouvez même éviter d'écrire du HTML si vous le souhaitez en définissant vos vues par programme. Cela vous permet de tester votre logique de vue (dans les applications Web, il y en a plus que d'habitude), ce qui n'est pas possible avec les frameworks HTML standard basés sur des modèles. L'autre avantage principal est qu'il dispose de méthodes intégrées qui vous permettent d'écrire Java code pour gérer les fonctionnalités dynamiques et asynchrones et tout est traduit automatiquement en JavaScript. Pas besoin d'écrire 4 langues différentes tout en écrivant votre application Web, il suffit d'écrire Java pour tout! Essayez-le, c'est amusant de travailler avec!

Un autre framework d'application Web qui attire beaucoup d'attention est Lift. Je n'ai pas d'expérience avec elle, mais de nombreux développeurs à qui j'ai parlé ont promu moi. Je crois qu'il utilise des modèles HTML avec du code Java comme back-end. Il est aussi apparemment très facile à démarrer et votre application Web a tourné vers le haut. Il a également intégré le support pour faire AJAX comme fonctionnalité. Utile dans la recherche au moins.

Il existe probablement beaucoup plus de frameworks d'applications Web qui répondraient à vos besoins. Elles ont toutes l'avantage d'être testé, indépendamment mises à jour et sécurisé*. Si vous lancez votre propre cadre pour ce projet, vous devez vous soucier de tout vous-même. Écrit un framework web qui n'offre rien nouveau serait comme écrit encore un autre langage de programmation qui n'est pas innovant; il est juste une perte de temps.

Je pense que ce que vous recherchez est plus dans le sens de la gestion ou du contrôle de votre tableau de bord. Je suis en train de concevoir quelque chose de similaire. Je vous suggère de regarder google app engine il peut être utilisé pour automatiser et contrôler ceci: https://developers.google.com/appengine/docs/whatisgoogleappengine

Regardez également ces tableaux de bord open-source: https://github.com/twilio/stashboard