Architecture pour développer une application en java qui pourrait aussi être utilisée avec l'interface desktop et web

Question

Je développe une application ou un service java pour exécuter des commandes à distance ou d'autres applications et recevoir les résultats de ces commandes. Et je pense à projeter cette application pour pouvoir l'utiliser avec une interface swing ou une interface web.

Je dois faire attention aux paramètres pour passer mes cours et comment je vais traiter les résultats. Je dois utiliser une architecture et un projet qui me permettent d'utiliser mes cours avec une application de bureau ou une application web. Je crois que ceci est lié à la conception d'API et de service. Certaines applications populaires disposent d'une interface Web ou d'un tableau de bord pour les services de contrôle, et les services sont gérables par des agents installés pour exécuter certains démons, services ou applications. Pour démarrer ou arrêter des commandes pour les systèmes de bases de données, les services d'annuaire et autres tâches

Il existe des guides sur le développement d'applications et de services dans java que je peux utiliser avec des environnements Web et de bureau. J'abuse d'une bouchée à ce sujet, parce que dans mon esprit si je choisis de développer ceci avec une approche de balançoire toutes les pensées deviennent claires pour moi. Mais quand j'imagine le même projet en utilisant la perspective web, je perds mes directives.

Désolé et j'espère que quelqu'un pourrait m'entendre. :-P

Answer 1

J'ai récemment été dans une situation similaire pendant que je commençais à travailler sur un simple CMS. Je voulais que mon moteur cms soit libre de ce que l'interface utilisateur/client est utilisé pour interagir avec elle et finalement je me suis contenté d'une approche orientée Web Service. En tant qu'étudiant de RESTful WS/ROA, j'aime généralement adopter cette approche. Si je comprends bien votre problème, je le concevrais comme étant que chaque programme externe, service, service web auquel je souhaite fournir un accès à distance serait une 'Application' à mon service Web, où 'Application' serait une ressource'. L'exécution d'actions sur la ressource 'Application' impliquerait l'exécution de requêtes GET avec différents paramètres de requête. La manière dont «Application» infère dépend de la ressource «Application».

Une approche similaire que j'ai prise dans le moteur CMS est de générer des représentations pour un contenu. Je supporte le template Ruby (JRuby), Groovy, JavaScript (Rhino) et Velocity pour générer une représentation. L'utilisateur crée le script de modèle en tant que ressource et se réfère ensuite à la définition du type de contenu. Les clients sont fournis des URI à la représentation à partir des formats de contenu génériques de contenu (Atom XML, JSON) et lors de leur récupération, ils reçoivent la sortie générée par le script. Je suis tenté de prendre une approche similaire pour votre problème. Cela non seulement séparerait l'interface utilisateur des objets métier, mais offrirait également une certaine souplesse pour ajouter de nouveaux services backend à long terme. Comme outils pour RESTful WS sur Java, je recommanderais, Jersey, Abdera, Jackson. À titre d'exemple pour comment les utiliser ensemble, vous pouvez jeter un oeil sur le projet CMS, j'étais referring to.

Answer 2

Considérons spring et MVC architecture. Aucun d'entre eux n'est limité au développement Web, mais ils sont largement utilisés en tant que tels.

Answer 3

Vous pouvez regarder dans Naked Objects, où vous développez un modèle d'objet de domaine et obtient l'interface utilisateur plus ou moins gratuitement (vous pouvez obtenir une interface graphique de bureau, et diverses formes d'interfaces Web). Cette approche n'est probablement pas réalisable si vous développez une application destinée au public, mais plutôt adaptée aux applications développées pour les utilisateurs experts.

Answer 4

Salut, je vous suggère de construire votre système avec une approche modulaire telle que vous avez toute votre logique métier est exposée en tant que service accessible par REST, en plus vous créez peut avoir la couche d'application Web et un couche de bureau.

schemantically il ressemblera à un niveau supérieur

weblayer/de bureau {--------- interface REST} {------- logique métier} ----- EIS

et modularisation vous pouvez envisager OSGI espère que cela aide