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

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

Il existe de nombreuses 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 motivons 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 d'une valeur quelconque, vous devrez au moins décrire les principales technologies et idées utilisées dans l'architecture que vous décrivez. Et le dernier mais non le moindre, lorsque devrions-nous utiliser votre architecture?

Je vais commencer...

Vue d'ensemble de l'architecture

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

  • Persistance
  • Affaires
  • Présentation

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

Persistence <-> Business <-> Presentation

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

Persistance

Effectue créer, lire, mettre à jour et supprimer (CRUD) les opérations de persistance. Dans notre cas, nous utilisons (Java Persistence API) JPA et nous utilisons actuellement Hibernate comme fournisseur de persistance et utilisons son EntityManager.

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

De plus, cette couche stocke également les entités JPA qui sont des choses comme Account, ShoppingCart etc.

Affaires

Toute logique liée à la fonctionnalité de l'application Web se trouve dans cette couche. Cette fonctionnalité pourrait initier un transfert d'argent pour un client qui souhaite payer un produit en ligne en utilisant sa carte de crédit. Il pourrait tout aussi bien être la création d'un nouvel utilisateur, la suppression d'un utilisateur ou du calcul de l'issue d'une bataille dans un jeu web.

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

Lorsque AccountManager doit effectuer des opérations CRUD il rend les appels appropriés à une instance de AccountManagerPersistence, qui est une classe dans la couche de persistance. Une esquisse approximative 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 container manager transactions donc nous n'avons pas à faire de démarcation de transaction nous-mêmes. Ce qui se passe essentiellement sous le capot, c'est que nous initions une transaction en entrant dans la méthode SLSB et la validons (ou la annulons) immédiatement avant de quitter la méthode. C'est un exemple de convention sur la configuration, mais nous n'avons pas encore eu besoin de quoi que ce soit d'autre que la valeur par défaut, requise.

Voici comment le tutoriel Java EE 5 de Sun explique Attribut de transaction requis pour les JavaBeans d'entreprise (EJB):

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

L'attribut requis est l'implicite attribut de transaction pour tous méthodes de bean d'entreprise en cours d'exécution avec transaction gérée par conteneur démarcation. Vous ne définissez généralement pas l'attribut requis sauf si vous avez besoin pour remplacer une autre transaction attribut. Parce que la transaction les attributs sont déclaratifs, vous pouvez facilement les modifier plus tard.

Présentation

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

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

Avantages et inconvénients avec le 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 métier.
  • Il est facile pour nous d'échanger notre couche de présentation en autre chose, 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 bien.
  • Utilisation des servlets + JPA 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 censée nous faciliter la création d'un système haute disponibilité avecéquilibrage de charge etbasculement . Les deux que nous pensons que nous devons avoir.

Contre

  • 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é JPA. Si vous avez autant que possible à la persistance dans les classes de persistance, comme dans notre architecture, cela répartira les emplacements où vous pouvez trouver des requêtes pour inclure également les entités JPA. Il sera plus difficile d'avoir une vue d'ensemble des opérations de persistance et donc plus difficile à maintenir.
  • Nous avons des entités JPA dans notre couche de persistance. Mais Account et ShoppingCart, ne sont-ils pas vraiment des objets métier? Cela se fait de cette façon car vous devez toucher ces classes et les transformer en entités que JPA sait faire 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's), également connus sous le nom d'objets de valeur (VO). Il en résulte unmodèle de domaine anémique car les objets métier n'ont pas de logique propre à l'exception des méthodes d'accesseur. Toute la logique est faite par nos gestionnaires dans la couche métier, 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 tout objet l'orientation n'est pas le seul paradigme de programmation qui a donné des résultats.)
  • Utiliser EJB et 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 Servlet + JPA. Utilisez Google pour plus d'informations sur ces problèmes.
  • Comme les transactions sont fermées lors de la sortie de la couche métier, nous ne pouvons charger aucune information des entités JPA qui est configuré pour être chargé à partir de la base de données lorsque cela est nécessaire (en utilisant fetch=FetchType.LAZY) à l'intérieur de la couche de présentation. Cela déclenchera une exception. Avant de renvoyer une entité contenant ce type de champs, nous devons nous assurer d'appeler le getter correspondant. Une autre option consiste à utiliser Java Persistence Query Language (JPQL) et à faire un FETCH JOIN. Cependant, ces deux solutions sont un peu lourdes.
Author: user14070 , 2008-11-13
Source

10 answers

Ok je vais en faire un (plus court):

  • Frontend : Tapisserie (3 pour les projets plus anciens, 5 pour les nouveaux projets)
  • Couche d'affaires: Printemps
  • DAO: Ibatis
  • Base de données : Oracle

Nous utilisons le support des transactions Sping et commençons les transactions en entrant dans la couche de service, en se propageant jusqu'à l'appel DAO. La couche de service a la connaissance du modèle le plus bussines, et les DAO font un travail CRUD relativement simple.

Une requête plus compliquée les choses sont traitées par des requêtes plus compliquées dans le backend pour des raisons de performances.

Les avantages de l'utilisation de Spring dans notre cas sont que nous pouvons avoir des instances dépendantes du pays/de la langue, qui sont derrière une classe Proxy Spring. En fonction de l'utilisateur dans la session, l'implémentation correcte du pays/de la langue est utilisée lors d'un appel.

La gestion des transactions est presque transparente, rollback sur les exceptions d'exécution. Nous utilisons autant que possible des exceptions non cochées. Nous avons utilisé pour faire vérifié exceptions, mais avec l'introduction de Spring, je vois les avantages des exceptions non cochées, ne gérant que les exceptions lorsque vous le pouvez. Il évite beaucoup de choses "catch/rethrow" ou "jette".

Désolé, c'est plus court que votre message, j'espère que vous trouverez cela intéressant...

 18
Author: Rolf, 2016-10-31 20:09:31

Technologies De Développement Web Basées Sur Java Idéales Aujourd'Hui.

Couche Web:

HTML+CSS+Ajax+JQuery

Couche de traitement du contrôleur Web/Action/Requête RESTful:

Cadre de jeu

Logique métier/Couche de service:

Utilisez du code Java pur aussi longtemps que possible. On peut faire la fusion des services Web ici.

Couche de transformation de données XML/JSon:

XMLTool(Recherche Sur Google Code),JSoup,Google GSon,XStream,JOOX (Recherche Sur Google Code)

Couche de persistance:

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

 18
Author: Rakesh Waghela, 2011-08-22 12:08:54

Voici mes 5 cents

Présentation

Android, angulaire.JS WebClient, OAUTHv2

API

REST, Jersey (JAX-RS), Jackson( JSON de - / sérialisation), DTO-objets (différents des modèles logiques métier)

Logique métier

Printemps pour DI et gestion des événements. Approche DDD-ish des objets modèle. Les tâches plus longues sont déchargées avec SQS dans les modules de travail.

DAO

Modèle de référentiel avec Spring JDBC-templates pour stocker les entités. Redis (JEDIS) pour les classements, en utilisant des listes Ordonnées. Memcache pour le magasin de jetons.

Base de données

MySQL, Memcached, Redis

 9
Author: Pepster, 2015-08-23 16:42:44

Ce que nous avons suivi dans notre projet est:

Technologie frontale

  • AngularJS
  • HTML5
  • css3
  • Javascript
  • Bootstrap 3

API

  1. RESTE
  2. MAILLOT (JAX-RS)
  3. RASSUREZ-VOUS
  4. BOTTE À RESSORT
  5. Jackson
  6. sécurité de printemps

La Logique Des Affaires

  • DONNÉES DE PRINTEMPS

  • Données de PRINTEMPS MongoDB

Base de données

  • MongoDB

Serveur (Pour la mise en cache)

  • redis
 7
Author: CandleCoder, 2015-09-28 11:38:40

Nous utilisons toujours la pile habituelle Struts-Spring-Hibernate.

Pour les applications futures, nous examinons Spring Web Flow + Spring MVC + Hibernate ou Printemps + Hibernation + Services Web avec Flex frontal.

Une caractéristique distincte de notre architecture est la modularisation. Nous avons un certain nombre de modules, certains commençant par 3 à 30 tables maximum dans la base de données. La plupart des modules se composent d'affaires et de projet web. Le projet d'entreprise détient la logique d'entreprise et de persistance tandis que le web détient présentation de la logique.
Au niveau logique, il y a trois couches: Affaires, Persistance et Présentation.
Dépendances:
La présentation dépend des affaires et de la persistance.
La persistance dépend des affaires.
Business ne dépend pas des autres couches.

La plupart des projets d'entreprise ont trois types d'interfaces (remarque: pas d'interface graphique, c'est une couche d'interface java programmatique).

  1. Interface que presentation utilise en tant que client
  2. Interface que l'autre les modules utilisent quand ils sont le client du module.
  3. Interface pouvant être utilisée à des fins administratives du module.

Souvent, 1 prolonge 2. De cette façon, il est facile de remplacer une implémentation de module par une autre. Cela nous aide à adopter à différents clients et à intégrer plus facilement. Certains clients n'achèteront que certains modules et nous devons intégrer les fonctionnalités qu'ils ont déjà. Étant donné que l'interface et la couche d'implémentation sont séparées, il est facile à rouler sortie de l'implémentation du module ad-hock pour ce client spécifique sans affecter les modules dépendants. Et Spring Framework facilite l'injection de différentes implémentations.

Notre couche métier est basée sur POJOs. Une tendance que j'observe est que ces POJOs ressemblent à des DTO. Nous souffrons de modèle de domaine anémique . Je ne sais pas trop pourquoi cela se produit, mais cela peut être dû à la simplicité du domaine de problème de beaucoup de nos modules, la plupart du travail est CRUD ou dû aux développeurs préférant placer la logique ailleurs.

 4
Author: Dan, 2009-03-17 16:37:05

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

Une exigence majeure était que l'application prenne en charge les mobiles / autres appareil. La demande doit également être extensible ou souple changements dans les choix technologiques.

Couche De Présentation:

  • JSP/JQuery (côté Client MVC)
  • Android natif
  • iPhone natif

  • Web mobile (HTML5 / CSS3 / Responsive la conception)

  • Contrôleurs de REPOS de ressort (Peut changer à JAX-RS)

Niveau de service aux entreprises:

Spring @ Service (Peut changer en EJB sans état)

Couche D'Accès Aux Données:

Spring @ Repository (Peut changer en EJB sans état)

Niveau de ressource:

Entités Hibernate(JPA) (peuvent changer en n'importe quel ORM)

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

 3
Author: Amritendu De, 2014-11-02 18:17:32

À mon humble avis, la plupart d'entre nous ont un dénominateur commun. Au moins dans le back-end, nous avons une forme de conteneur IOC/DI et un cadre de persistance. Personnellement, j'utilise Guice et Mybatis pour cela. Les différences sont dans la façon dont nous implémentons la couche view/UI/presentation. Il y a 2 options principales ici (peut-être plus) .. Basé sur l'action (URL mappées aux contrôleurs) et basé sur le composant. Actuellement, j'utilise la couche de présentation basée sur les composants (en utilisant wicket). Il imite parfaitement un environnement de bureau où j'utilise composants et événements par opposition aux URL et contrôleurs. Je cherche actuellement une raison pour laquelle je devrais migrer vers ce type d'architecture de contrôleur d'URL (c'est ainsi que je me suis retrouvé sur cette page). Pourquoi le battage médiatique sur les architectures RESTful et sans état.

Pour répondre à cette question en bref: j'écris des applications Web avec état en utilisant un framework orienté composant au-dessus du conteneur Guice IOC et je mets des données dans une base de données relationnelle en utilisant Mybatis.

 2
Author: joshua, 2013-12-17 18:56:55

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

  1. Ressort WS / Rest / JSP frontal
  2. Spring MVC for business service logic, contenant la logique de la couche de présentation ainsi que les transactions Spring
  3. Interface de communication du service composant, consultée via EJB par business services. Les EJB définissent leurs propres limites de transaction qui peuvent rejoindre les transactions Spring.
  4. Implémentations de service de composants, encore printemps composants
  5. Couche d'intégration, MyBatis pour les intégrations de bases 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 un fournisseur de fonctionnalités commun pour tous les srevices.

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

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

 1
Author: eis, 2014-06-02 20:21:47

J'ai travaillé sur des projets qui utilisent ce modèle de gestionnaire rigide. Historiquement, j'étais un grand partisan de la hiérarchie rigide où tout rentre dans une boîte soignée. Comme je l'avancement de ma carrière, je trouve que c'est forcé, dans beaucoup de cas. Je crois que l'adoption d'un état d'esprit plus agile envers la conception d'applications conduit à un meilleur produit. Ce que je veux dire par cela créer un ensemble de classes qui résolvent le problème à portée de main. Plutôt que de dire " Avez-vous construit un gestionnaire pour ceci et cela?"

Le le projet actuel sur lequel je travaille est une application Web avec une combinaison d'appels Spring MVC et RestEasy JSON/Ajax. Du côté serveur intégré à nos contrôleurs se trouve un niveau de données basé sur une façade sensible avec JPA / Hibernate pour un accès direct à la base de données, un accès EJB et des appels de service Web basés sur SOAP. Lier tout cela ensemble est un code de contrôleur java personnalisé qui détermine ce qu'il faut sérialiser en tant que JSON et retourner au client.

Nous ne passons presque pas de temps à essayer de créer un pattern optant plutôt pour adopter l'idée" Pire est mieux " de la philosophie de conception Unix. Étant donné qu'il est beaucoup mieux de colorer en dehors des lignes et de construire quelque chose de sensible, rapidement que de construire quelque chose qui adhère à un tas de mandats de conception stricts.

 0
Author: nsfyn55, 2011-08-22 12:41:52

Les composants de Architecture d'application Web comprennent:

1: Navigateur: Interaction client 

        HTML
        JavaScript
        Stylesheet

2: Internet

3: Serveur web 

        CSS
        Image
        Pages(Java render )

4 : Serveur d'applications 

        App Webapp (Java interaction)
        Others WebApps

5 : Serveur de base de données 

        Oracle, SQL, MySQL

6 : Données

 0
Author: iCrazybest, 2014-09-14 16:36:05