Conseils sur la hiérarchie d'un projet

Bonjour,

Je souhaite faire une application desktop qui se divise en deux parties.
- Le FrontOffice qui sera utilisé par la majorité des personnes.
- Le BackOffice qui sera utilisé par les managers ou administrateurs (paramétrage, configuration, statistiques, ....)

Ma question est la suivante :
Vaut-il mieux gérer le tout dans un seul projet et gérer les deux aspects a l'aide des packages ou faire 3 projets distincts ?

A savoir que je prévois que le backoffice peut-être lancé seul ou lancé via le FrontOffice si l'utilisateur a les droits nécessaires.

Solution 1 Projet :
monproj.common.entity
monproj.common.service
monproj.common.utils
monproj.backoffice.service
monproj.backoffice.model
monproj.backoffice.gui
monproj.frontoffice.service
monproj.frontoffice.model
monproj.frontoffice.gui

Solution 3 projets
ProjMain
¦- common.entity
|- common.service
|- common.util

ProjBackOffice
|- backoffice.entity
|- backoffice.service
|- backoffice.model
|- backoffice.gui

ProjFrontOffice
|- frontoffice.entity
|- frontoffice.service
|- frontoffice.model
|- frontoffice.gui

Quels sont les avantages et les inconvénients de chaque solution d'après votre expérience ?

Si je me trompe pas, dans la solution multi-projet, j'aurai 3 jar a la sortie, est-ce un avantage ?

N'y a t'il pas plus de risque de travailler en 3 projets distincts au point de vue impact d'un projet sur un autre ?

Si je fais une mise a jour de la partie backoffice, dois-je regénérer et déployer les 3 projets ou puis-je uniquement déployer le jar du backoffice?


Merci beaucoup

Salut,

Il est possible d'avoir 3 projets qui génèrent 2 Jars : un jar "user" et un jar "admin", et donc ton projet "admin" serait comme un module ajouté à ton projet "user", ce qui ferait que tu ne distribuerais pas le même jar aux utilisateurs normaux et aux admins, mais les deux projets étant bien distincts, une modif de l'un n'impacterait pas l'autre.

Donc je verrais plutôt la fonctionnalité "admin" comme un "module" de ton application, qui lui permet d'avoir des fonctionnalités supplémentaires. De plus, côté sécurité, c'est mieux, parce qu'ainsi les utilisateurs n'embarquent pas le code admin sur leur poste, et ne peuvent donc pas bidouiller l'appli, alors que si tu fournis le code admin à tes users normaux, tu cours le risque qu'un petit malin trouve le moyen de cracker ton appli "admin" :)

A+

Merci pour la réponse.

J'ai néanmoins une question: Qu'entends tu par module ?
Est-ce ceci : http://baptiste-wicht.developpez.com...n/application/

Si oui, je pourrais imaginer que mon appli Core ne fait rien de spécial si ce n'est charger le module FrontOffice si il est dispo et/ou le module Backoffice si il est dispo.

Est-ce que j'ai bien compris ?
Donc au final j'ai 3 projets dans eclipse. Application, FrontOffice et BackOffice.
Pour les utilisateurs du système j'installe Application.jar et FrontOffice.jar
Pour les managers Application.jar et BackOffice.jar
Pour moi les 3 :)

C'est bien cela?

Ce qui me permettrait aussi par la suite de créer 4ième projet Stock par exemple pour gérer les stocks ou un module compta pour gérer la compta.

Question: Les services utiliser par un seul module, par exemple StockService se trouvera dans le projet Stock.
Quant est il des services utilisé par plusieurs module ex: UserService, ArticleService, ...
Même question pour mes entitées ex: Utilisateur, Article, .....

Alors oui le principe de "modularité" est expliqué dans l'article que tu as fournis :)

Pour bien faire les choses, et si tu as le temps, voici comment je verrais l'architecture de tes projets, selon les besoins que je semble comprendre de ton énoncé :

1) Une application "Application.jar" qui sera celle qui sera systématiquement déployée aura au moins 4 objectifs :

• Permettre aux utilisateurs de s'identifier, pour leur proposer les modules associés à leur compte
• Télécharger le ou les modules nécessaires, si l'authentification a réussi
• Permettre la mise à jour dynamique, par interrogation du serveur sur les dernières montées de version
• Permettre l'installation de modules par fichier simple, si il n'y a pas moyen de se connecter

2) Un module "User.jar" qui contiendra le code, ainsi que les écrans propre à l'utilisation en mode User.
3) Un module "Admin.jar" pour les besoins d'administration
4) Un module "SuperAdmin.jar", pour tes besoins à toi ;)
5) Un module "Global.jar" qui contiendra toutes les classes communes et les librairies du projet
6) Une application côté serveur, interrogeable à distance, sur laquelle tu auras déployé une appli web qui proposera les services d'authentification, de téléchargement, et peut-être d'autres services si besoin (enregistrement de préférences des utilisateurs, ou bien récolte de données, etc)

En procédant ainsi, tu peux te baser sur une "Application.jar" suffisamment stable pour qu'elle n'ait plus besoin d'être redéployée, et seul les modules se mettraient à jour par le web. Ce mécanisme peut permettre à l'avenir que tu ajoutes d'autres modules, que tu spécifies plus finement les droits d'accès (par exemple, telle personne pourrait administrer (donc elle peut télécharger le module Admin) mais ne peut pas faire de reporting (le module Reporting sera inaccessible).

Après, sans savoir précisément de quoi parle ton application ni ce qu'elle traite, je ne peux pas te donner ma vision précise des choses, mais en tout cas l'intérêt d'une architecture modulaire dès le départ, c'est de séparer au maximum les dépendances entre les modules, et de ne charger que les modules nécessaires, ce qui allège l'application, et la rend aussi plus "secure".

Si tu as besoin d'autres infos n'hésite pas :)

A+

Merci pour les infos.

N'étant pas du tout a l'aise avec les appli Web, je vais faire une application Desktop.
En fait je reprend Java après plus de 12ans d'abstinence :) , Oui j'ai pas mal de retard, mon dernier prog java date de l'école en Java 1.2 lol

L'application en question est un logiciel de caisse que je fais pour deux amis (une épicerie et un marchant de journaux).

La partie FrontOffice sera la caisse (Vente)
La partie BackOffice sera la gestion des articles et le paramètrage du FrontOffice (Prix, Tva, Rapport de caisse, utilisateur, permission, disposition des article sur le clavier virtuel, ....)

Je pars sur quelque chose de très simple au départ, juste gestion de la vente.
Par la suite, ils voudraient la gestion du stock, la compta, déclaration TVA, Gestion fournisseurs avec commande automatique, Gestion clients, ... (Ce sera donc a chaque fois des modules supplémentaires)

Si cela fonctionne bien, donc dans longtemps :) , On le donnerait a d'autres personnes en version gratuite (BackOffice et FrontOffice), les modules supplémentaires serait payant mais bon c'est a voir .......
On y est pas encore....

Moi je voulais surtout un projet concret pour me remettre dans Java et combler le gouffre qui sépare les connaissances de mes études au jour d'aujourd'hui. En discutant avec eux, ils m'ont proposé tout les deux la même chose, cela m'a motivé.
J'ai pas mal potasser déjà certains sujets comme JPA, Hibernate, ...
Je sais pas si le projet va aboutir mais je suis certains que je vais apprendre beaucoup et puis c'est plus motivant d'avoir un but réel (Faire plaisir aux amis)
Je pose beaucoup de questions car je souhaite partir sur des bonnes bases dès le départ. désolé :(

Voilà pour la petite histoire.

Puis-je abuser en te posant encore une question?
On est d'accord que selon le principe des modules, chaque module est un projet a part entière et non un package au sens java.

Oui c'est beaucoup plus motivant d'apprendre (ou de réapprendre) en immersion dans un cas concret :D

Alors pour répondre à ta question tout d'abord : oui je parlais de projets java indépendants, les packages servent à s'organiser au sein d'un même projet/module.

Ensuite, selon moi, nous vivons à une époque de plus en plus "connectée", et si tu souhaites remettre un pied dans l'informatique, t'intéresser aux applications web sera un plus pour le futur, et ton application me semble particulièrement adaptée à ce mode de fonctionnement (si par exemple si as un jour 10 clients, et que tu dois faire une modif pour tout le monde, dans le cadre d'un application web, tu déploies la modif une fois que tu déploies sur ton serveur de prod, et tout le monde en profite en temps réel).

Et puis le web je trouve ça plus facile que Swing :) je ne t'ai même pas demandé la techno que tu utilisais, mais j'ai déduis que c'était Swing.

Effectivement c'est Swing :)

Durant c'est 12 dernières années, j'ai fait 7 ans de WinDev et 5 ans d'un langage propriétaire inventé par ma boite (Langage procédural, donc non OO ressemblant un peu a du VB6)
Autant dire que je vaux plus rien sur le marché, c'est pourquoi j'ai décidé de me remettre a la page.

J'y beaucoup pensé a me lancer dans le Web, mais je pense qu'il est plus sage de le faire en plusieurs étapes:
1. Je refais connaissance avec le monde JAVA en Mode Desktop avec Swing
2. Je plonge dans le web avec un acquis Java "pur" bien ancré.

De plus, cela suppose que je dispose d'un serveur Applicatif JBOSS perso pour le déploiement ou un serveur avec TOMCAT si je passe en full web. (Si j'ai bien compris)
De mon temps (Rooo le vieux...), on ne parlait que de desktop et applet :)

Par la suite je me pencherai aussi sur Android car je penses que c'est porteur également. On pourrait imaginer que le patron visualise les ventes a distance par exemple :) (là je rêve)

Pour conclure, j'ai peur de me noyer dans toutes ces nouvelles technologies, je préfère les prendre une a une. Et puis, l'avantage du mode desktop, c'est que lors d'une mise à jour, tu va voir le client, tu garde donc le contact avec celui-ci :)

En tout cas merci beaucoup pour tes explications très claires et précises !
J'espère que l'on se croisera encore sur forum :)