architecture en couches en Java EE

Question

J'ai une question que je ne l'ai jamais été en mesure de résoudre:

Compte tenu de ces deux l'architecture

1er

UI layer 
    | 
Application layer 
    | 
Domain Layer 
    | 
Infrastructure Layer 

2ème

Client Tiers 
    | 
Presentation Tiers 
    | 
Business Tiers 
    | 
Integration Tiers 
    | 
Resources Tiers 

Qu'est-ce que sont la différence entre eux.

Où se trouvent les beans entité dans ces architectures. Si j'ai une couche de gestion avec un objet qui implémente la logique métier, pourquoi devrais-je ajouter un comportement dans les beans entité. J'ai lu quelque part que c'est un anti modèle d'avoir des objets de modèle de domaine sans comportement.

Merci

Mise à jour

Ceci est en fait un projet (formation) que je dois faire pour obtenir mon msc dans les systèmes distribués.

Ce sont en fait les technologies que je utilise

Struts 2 JPA HSQLDB

Donc, si je comprends bien

Mon application se composent de

Une couche client (Navigateur web Une couche de présentation (struts 2) Une couche métier (POJOs + JPA) Une couche d'intégration (avec DAOs hibernate) Une couche de ressources (HSQLDB)

Mais comme la couche de présentation, de gestion et d'intégration est implémentée sur le même serveur (tomact), je n'ai qu'une architecture à trois niveaux. Ai-je raison ?

En ce qui concerne l'inclusion du comportement dans mes objets JPA, c'est généralement ce que j'avais l'habitude de faire: Avoir un dao pour chaque entité JPA. Avoir un bean (comme un EJB) qui gèrerait la logique métier requise. Donc, je ne mets jamais beahvior sur les objets JPA.

Dire par exemple que je voulais faire une demande d'achat. J'aurais un catalogueManager qui m'aiderait à interagir avec des articles, des fournisseurs. J'aurais aussi un EmployeeManager qui m'aiderait à interagir avec les employés. Et enfin un PurchaseRequestManager qui utiliserait les deux objets métier précédents pour faire un PurchaseRequest. Maintenant, ce que vous me dites est de mettre les méthodes que j'ai dans PurchaseManager dans l'entité JPA PurchaseRequest, et faites de même pour les méthodes dans EmployeeManager => pour les mettre dans l'entité JPA Employé.

Mais que se passerait-il si mon objet employé était également utilisé pour le département des ressources humaines, j'aurais aussi besoin d'y mettre d'autres méthodes. Pour une grande application, j'aurais beaucoup de méthodes dans l'entité JPA des employés. Cela ne serait-il pas contre-productif?

grâce

Answer 1

Dans mon esprit, les « couches » sont une séparation logique, sans implication d'une topologie de déploiement. Les «niveaux» concernent le déploiement physique. Par exemple, la logique de la couche UI peut être implémentée complètement dans un client lourd, déployée sur un niveau client sur le bureau et sans niveau de présentation distinct, ou peut être une application Web 2.0 Browser, avec la couche UI répartie entre un client UI Javascript dans le navigateur et le niveau de présentation dans un serveur.

Maintenant sur Entitiy Beans. Premièrement, les Entity Beans sont dans EJB 3 remplacés par JPA - nous annotons les objets pour contrôler leur persistance.

Je pense que vous avez deux types de logique métier, celle qui concerne le comportement des classes persistantes individuelles telles que les clients, les commandes, les employés, les expéditions, les étudiants, les cours ou autre, et leur logique est à un niveau plus élevé que cela, traitant de combinaisons de ces classes.

Il me semble raisonnable que la logique concernant le comportement d'un client, par exemple, soit dans la classe Customer. Un tel comportement peut être assez trivial, par exemple certains types de validation et de récapitulation (par exemple, la valeur totale de la commande), mais c'est une logique de domaine qui peut raisonnablement se trouver dans ces objets de domaine. Ainsi, nos objets JPA ont deux rôles, implémentant la logique de domaine et gérant également la persistance grâce à leur annotation. Le statut architectural de ces annotations est intéressant, elles sont effectivement la «colle» entre le domaine et l'infrastructure.

Answer 2

De Wikipedia:

Les concepts de la couche et de niveau sont souvent utilisés de façon interchangeable. Cependant, un point de vue assez commun est qu'il existe effectivement une différence , et qu'une couche est un mécanisme de structuration logique pour les éléments qui constituent la solution logicielle, alors qu'un niveau est un mécanisme de structuration physique pour le système Infrastructure.

Fondamentalement, il y a 3 "parties" à l'adresse:

1. clients - c'est où la présentation se produit, et où existe (Javascript) programmation côté client pour une interaction dynamique avec votre application.

2. Entreprise - C'est là que toute votre logique métier existe. Algorithmes, modèles de domaines, la "viande" de votre application. Les EJB vivent ici, si vous les utilisez.

3. Données - généralement votre base de données à laquelle vous accédez à partir de votre couche de gestion.

Vos beans entité (obsolète) existent dans la couche de gestion. Mais n'utilisez pas alors, utilisez JPA car c'est plus moderne et beaucoup moins encombrant.

Vous pouvez également utiliser des entités JPA pour la logique métier, car elles sont assez "légères", il n'est donc pas nécessaire d'effectuer une séparation totale.

Efforcez-vous de simplicité, pas pour l'utilisation excessive de "l'architecture", "les modèles de conception", "modèle d'entreprise" ou toute autre chose qui semble trop entreprise.