Décrivez l'architecture que vous utilisez pour les applications Web Java?


Answers

Technologies de développement Web basées sur Java idéales aujourd'hui.

Couche Web:

HTML + CSS + Ajax + JQuery

Contrôleur Web RESTFul / Action / Couche de traitement des demandes:

Jouer le cadre

Logique métier / couche de service:

Utilisez le code Java pur aussi longtemps que possible. On peut faire la fusion de services web ici.

Couche de transformation de données XML / JSon:

XMLTool (Recherche sur Google Code), JSoupe, Google GSon, XStream, JOOX (Recherche sur Google Code)

Couche de persistance:

CRUD: JPA ou SienaProject ou QueryDSL / Requêtes complexes: JOOQ, QueryDSL

Question

Partageons les architectures d'applications web basées sur Java!

Il y a beaucoup d'architectures différentes pour les applications web qui doivent être implémentées en utilisant Java. Les réponses à cette question peuvent servir de bibliothèque de diverses conceptions d'applications Web avec leurs avantages et leurs inconvénients. Bien que je réalise que les réponses seront subjectives, essayons d'être aussi objectifs que possible et de motiver les avantages et les inconvénients que nous énumérons.

Utilisez le niveau de détail que vous préférez pour décrire votre architecture. Pour que votre réponse soit utile, vous devez au moins décrire les principales technologies et idées utilisées dans l'architecture que vous décrivez. Et last but not least, quand devrions-nous utiliser votre architecture?

Je vais commencer...

Vue d'ensemble de l'architecture

Nous utilisons une architecture à trois niveaux basée sur des standards ouverts de Sun comme Java EE, Java Persistence API, Servlet et Java Server Pages.

  • Persistance
  • Entreprise
  • Présentation

Les flux de communication possibles entre les couches sont représentés par:

Persistence <-> Business <-> Presentation

Ce qui, par exemple, signifie que la couche de présentation n'appelle jamais ou n'effectue pas d'opérations de persistance, elle le fait toujours via la couche de gestion. Cette architecture est destinée à répondre aux exigences d'une application web à haute disponibilité.

Persistance

Effectue les opérations de persistance create, read, update et delete ( CRUD ). Dans notre cas, nous utilisons JPA ( Java Persistence API ) et nous utilisons actuellement Hibernate comme fournisseur de persistance et utilisons son EntityManager .

Cette couche est divisée en plusieurs classes, chaque classe traitant d'un certain type d'entités (c'est-à-dire que les entités associées à un panier peuvent être traitées par une seule classe de persistance) et est utilisée par un et un seul gestionnaire .

En outre, cette couche stocke également les entités JPA , telles que Account , ShoppingCart etc.

Entreprise

Toute la logique liée à la fonctionnalité de l'application Web se trouve dans cette couche. Cette fonctionnalité pourrait être l'initiation d'un transfert d'argent pour un client qui veut payer un produit en ligne en utilisant sa carte de crédit. Il pourrait tout aussi bien s'agir de créer un nouvel utilisateur, de supprimer un utilisateur ou de calculer le résultat d'une bataille dans un jeu basé sur le Web.

Cette couche est divisée en plusieurs classes et chacune de ces classes est annotée avec @Stateless pour devenir un bean de session sans état (SLSB). Chaque SLSB est appelé un gestionnaire et par exemple un gestionnaire pourrait être une classe annotée comme mentionné appelé AccountManager .

Lorsque AccountManager doit effectuer des opérations CRUD, il effectue les appels appropriés à une instance de AccountManagerPersistence , qui est une classe dans la couche de persistance. Une ébauche de deux méthodes dans AccountManager pourrait être:

...
public void makeExpiredAccountsInactive() {
    AccountManagerPersistence amp = new AccountManagerPersistence(...)
    // Calls persistence layer
    List<Account> expiredAccounts = amp.getAllExpiredAccounts();
    for(Account account : expiredAccounts) {
        this.makeAccountInactive(account)
    }
}
public void makeAccountInactive(Account account) {
    AccountManagerPersistence amp = new AccountManagerPersistence(...)
    account.deactivate();
    amp.storeUpdatedAccount(account); // Calls persistence layer
}

Nous utilisons des transactions de gestionnaire de conteneurs afin que nous n'ayons pas à faire la démarcation de nos transactions. Ce qui se passe essentiellement sous le capot, c'est que nous démarrons une transaction lorsque nous entrons dans la méthode SLSB et que nous la validons (ou l'annulons) immédiatement avant de quitter la méthode. C'est un exemple de convention sur la configuration, mais nous n'avons pas eu besoin de rien d'autre que la valeur par défaut, Required, pour le moment.

Voici comment le didacticiel Java EE 5 de Sun explique l' attribut de transaction Requis pour Enterprise JavaBeans (EJB):

Si le client s'exécute dans une transaction et appelle la méthode du bean enterprise, la méthode s'exécute dans la transaction du client. Si le client n'est pas associé à une transaction, le conteneur démarre une nouvelle transaction avant d'exécuter la méthode.

L'attribut Required est l'attribut de transaction implicite pour toutes les méthodes de enterprise bean exécutées avec une démarcation de transactions gérée par conteneur. En règle générale, vous ne définissez pas l'attribut Required sauf si vous devez remplacer un autre attribut de transaction. Les attributs de transaction étant déclaratifs, vous pouvez facilement les modifier ultérieurement.

Présentation

Notre couche de présentation est en charge de ... la présentation! Il est responsable de l'interface utilisateur et présente des informations à l'utilisateur en créant des pages HTML et en recevant les entrées des utilisateurs via les requêtes GET et POST. Nous utilisons actuellement l'ancienne combinaison de Servlet + Java Server Pages ( JSP ).

La couche appelle des méthodes dans les gestionnaires de la couche de gestion pour effectuer les opérations demandées par l'utilisateur et pour recevoir des informations à afficher dans la page Web. Parfois, les informations reçues de la couche métier sont des types moins complexes que String et int egers, et à d'autres moments, des entités JPA .

Avantages et inconvénients avec l'architecture

Avantages

  • Avoir tout ce qui concerne une manière spécifique de faire de la persistance dans cette couche signifie seulement que nous pouvons passer de l'utilisation de JPA à autre chose, sans avoir à réécrire quoi que ce soit dans la couche de gestion.
  • Il est facile pour nous d'échanger notre couche de présentation en quelque chose d'autre, et il est probable que nous le ferons si nous trouvons quelque chose de mieux.
  • Laisser le conteneur EJB gérer les limites de transaction est agréable.
  • L'utilisation de + JPA de Servlet est facile (pour commencer) et les technologies sont largement utilisées et implémentées dans de nombreux serveurs.
  • L'utilisation de Java EE est supposée faciliter la création d'un système à haute disponibilité avec équilibrage de charge et basculement . Nous pensons tous les deux que nous devons avoir.

Les inconvénients

  • En utilisant JPA, vous pouvez stocker les requêtes souvent utilisées en tant que requêtes nommées en utilisant l'annotation @NamedQuery sur la classe d'entités JPA. Si vous avez autant que possible lié à la persistance dans les classes de persistance, comme dans notre architecture, cela étendra les emplacements où vous pouvez trouver des requêtes pour inclure également les entités JPA. Il sera plus difficile de surveiller les opérations de persistance et donc plus difficile à maintenir.
  • Nous avons des entités JPA dans le cadre de notre couche de persistance. Mais Account et ShoppingCart , ne sont-ils pas vraiment des objets de gestion? C'est fait de cette façon car vous devez toucher ces classes et les transformer en entités que JPA sait gérer.
  • Les entités JPA, qui sont également nos objets métier, sont créées comme des objets de transfert de données ( DTO ), également appelés objets de valeur (VO). Il en résulte un modèle de domaine anémique car les objets métier n'ont aucune logique propre, à l'exception des méthodes d'accès. Toute la logique est faite par nos gestionnaires dans la couche de gestion, ce qui se traduit par un style de programmation plus procédural. Ce n'est pas une bonne conception orientée objet, mais peut-être que ce n'est pas un problème? (Après toute l'orientation de l'objet n'est pas le seul paradigme de programmation qui a donné des résultats.)
  • L'utilisation d'EJB et de Java EE introduit un peu de complexité. Et nous ne pouvons pas utiliser purement Tomcat (l'ajout d'un micro-conteneur EJB n'est pas purement Tomcat).
  • Il y a beaucoup de problèmes avec l'utilisation de + JPA de Servlet. Utilisez Google pour plus d'informations sur ces problèmes.
  • Comme les transactions sont fermées à la sortie de la couche de gestion, nous ne pouvons charger aucune information des entités JPA configurée pour être chargée depuis la base de données quand elle est nécessaire (en utilisant fetch=FetchType.LAZY ) depuis la couche de présentation. Cela déclenchera une exception. Avant de renvoyer une entité contenant ces types de champs, nous devons être sûrs d'appeler les getters correspondants. Une autre option consiste à utiliser Java Persistence Query Language ( JPQL ) et faire un FETCH JOIN . Cependant, ces deux options sont un peu lourdes.



Ce que nous avons suivi dans notre projet est:

Technologie d'extrémité avant

  • AngularJS
  • HTML5
  • css3
  • Javascript
  • Bootstrap 3

API

  1. DU REPOS
  2. MAILLOT (JAX-RS)
  3. REPOS ASSURÉ
  4. BOTTE DE PRINTEMPS
  5. Jackson
  6. la sécurité du printemps

Logique d'entreprise

  • DONNÉES DU PRINTEMPS

  • Données SPRING MongoDB

Base de données

  • MongoDB

Serveur (pour la mise en cache)

  • Redis



Les composants de l' architecture d'application Web incluent:

1: Navigateur: interaction avec le client

        HTML
        JavaScript
        Stylesheet

2: Internet

3: Serveur Web

        CSS
        Image
        Pages(Java render )

4: Serveur d'application

        App Webapp (Java interaction)
        Others WebApps

5: Serveur de base de données

        Oracle, SQL, MySQL

6: Données




Voici une autre architecture web sur laquelle j'ai travaillé:

Une exigence majeure était que l'application prenne en charge les mobiles / autres périphériques. L'application doit également être extensible ou flexible aux changements dans les choix technologiques.

Niveau de présentation:

  • JSP / JQuery (MVC côté client)
  • Android natif
  • IPhone natif
  • Web mobile (HTML5 / CSS3 / Responsive design)

  • Contrôleurs Spring REST (peut changer en JAX-RS)

Niveau de service commercial:

Spring @Service (Peut être remplacé par EJB sans état)

Niveau d'accès aux données:

Spring @Repository (Peut être remplacé par EJB sans état)

Niveau de ressource:

Hibernate (JPA) entités (peut changer à n'importe quel ORM)

Vous pouvez trouver plus d'informations sur le livre qui suit cette architecture here .




Un peu différent, et je revendiquerais plus d'architecture java modulaire ici. Nous avons:

  1. Spring WS / Repos / JSP avant
  2. Spring MVC pour la logique de service métier, contenant la logique de la couche de présentation ainsi que les transactions Spring
  3. Interface de communication de service de composants, recherchée via EJB par les services métier. Les EJB définissent leurs propres limites de transaction pouvant joindre des transactions Spring.
  4. Implémentations de service de composants, encore une fois Composants de ressort
  5. Couche d'intégration, MyBatis pour les intégrations de base de données, Spring WS pour les intégrations de services Web, autres technologies d'intégration pour d'autres services
  6. Mainframes, bases de données, autres services sur d'autres serveurs ...

En plus de ce qui précède, nous avons les modules de bibliothèque partagée qui est fournisseur de fonctionnalités communes pour tous les srevices.

L'utilisation de différentes couches nous permet un découplage total et la modularité dont nous avons besoin. Nous sommes également en mesure d'utiliser pleinement la puissance de Java EE ainsi que Spring. Rien ne nous empêche d'utiliser JSF, par exemple, pour le frontal si nécessaire.

Comparé à l'architecture d'exemple par OP, je pense que cela peut être décrit comme ayant quatre couches principales au lieu de trois, quoique avec une torsion.