Discussion :

[sonia5]

Bonjour,

SVP, j'ai besoin de vos aides: dans un entretien; le recruteur m'a posé la question sur l'architecture d'une application que j'ai déjà réalisé, je lui ai expliqué qu'il s'agit de l'architecture MVC (M (Model) : ou j'utilise SpringDATA..., V(Vue): Angular, C(Controller): SpringRest, SpringSecurity...) et je lui ai décrit en détail la liaison entre ces parties, mais à la fin il m'a dit que ma explication ne s'agit pas de l'architecture d'une application ce que j'ai décrit c'est la structure, SVP s'il a raison, alors c'est quoi l'architecture d'une application ? est ce que je dois décrire les serveurs, les BDD utilisés?
SVP pourriez-vous m'orienter sur la bonne explication d'architecture d'une application JAVA J2EE?

Merci d'avance.

[OButterlin]

Disons qu'à la base, tu es déjà hors contexte JEE en parlant de Spring, Spring est à voir comme un concurrent de JEE, pas une partie de JEE

Qui plus est, tu mélanges les concepts, MVC est un pattern.
Pour ce pattern, le M représente les données de la vue, le V la vue, le C le contrôleur qui orchestre les requêtes/réponses.
Généralement, MVC est lié à un framework, JSF pour le standard JEE d'application web (avant JSF on avait Struts). Avoir le V sous angular, le M en SpringDATA et le C en Spring Rest, ça sonne faux... la logique voudrait que le modèle, la Vue et le contrôleur soient liés à Angular. Que celui-ci utilise un backend Spring, why not...

Pour ce qui est de l'architecture d'une application, on parlerait plutôt des couches applicatives et là, JEE offre une structuration assez importante et très large.
Un serveur JEE n'est pas uniquement lié à des applications web, on peut très bien (et même souvent) l'utiliser avec un client lourd (Swing, JavaFX, client C/C++ etc...).

Maintenant, dans le cas d'une application web, on aura généralement 3 couches :
- le client (navigateur web)
- le serveur d'application
- le serveur de base de données

Généralement, on a au moins 3 machines distinctes mais on peut très bien faire tourner le tout sur un seul poste, ne serait-ce que pour le développeur qui aura la base de données, le serveur d'application et le navigateur sur son poste (mais c'est un cas particulier).
Quand je dis 3 machines, ça peut aussi être bien plus, tout dépend du découpage voulu.

Le serveur d'application EE aura à sa charge de traiter les requêtes venant du client.
Pour ça, il dispose d'une multitude d'API (ce qui fait JEE) avec en particulier :
- un conteneur web pour faire tourner les servlet lequel pourra servir dans le cadre de framework dédiés (comme JSF2 par exemple)
- un conteneur d'EJB pour faire tourner la couche métier, laquelle pourra utiliser JPA pour l'API de persistence et JTA pour les transactions (gérées par le conteneur)
JPA étant une API, elle s'appuie sur une implémentation particulière (par défaut Hibernate sur un serveur Wildfly, EclipseLink sur un serveur Glassfish)

On pourrait également en option parler de l'API javax.mail si l'application doit envoyer des mails, des briques de messaging pour faire des traitements assynchrones etc...

Voilà ce qu'est JEE, une énorme boite à outil pour faire des applications d'entreprise (ou personnelle )

[sonia5]

Merci pour votre réponse, alors ce que j'ai compris pour décrire l'architecture d'une application web on doit présenter les couches de cet application (au moins client, serveur, BDD)
Mais ce que je n'ai pas bien compris pour le pattern MVC

Avoir le V sous angular, le M en SpringDATA et le C en Spring Rest, ça sonne faux... la logique voudrait que le modèle, la Vue et le contrôleur soient liés à Angular

dans le d'une aplication en Spring Data, SpringRest, Angular...), si on considère le M: SpringData, C: SpringRest alors ou est le V(View) et quel est le rôle d'Angular ?

Merci d'avance.

[OButterlin]

N'étant pas un spécialiste d'Angular, je ne vais pas m'avancer, mais de ce que j'en sais, Angular est un framework qui permet de développer un client riche à base de javascript html css, même si dans le framework, on utilise TypeScript, à la fin, c'est bien du javascript côté client, on parle de transpilation (ce qui me semble un peu ridicule, pourquoi ne pas utiliser directement javascript... mystère...).
Bref, Angular sert à développer une IHM côté client (browser web), Spring (and Cie) la partie métier côté serveur. La logique souvent utilisée est basé sur des services Rest pour demander et/ou manipuler les données fournies par le serveur.

Mais comme dit, je n'ai fait qu'éfleurer ce framework, au même titre que React ou VueJs, personnellement, j'utilise le stack complet JEE à grand renfort de JSF2+Primefaces et EJB+JTA+JPA pour la couche métier.
Des 3 framework javascript cités, ma préférence va largement à VueJs, simple, efficace, facile à coupler à tout et n'importe quoi.
A l'inverse, Angular me semble ultra rigide dans son approche...
Ceci dit, je ne suis pas là pour juger du bien-fondé de tel ou tel framework, chacun ses choix, il n'y a pas forcément de bon ou de mauvais outils/framework, il y a surtout ceux qu'on maîtrise