Discussion :

[Fayne38]

Bonsoir à toutes et à tous.

Dans le cadre d'un projet d'études, je dois réaliser une application ayant pour critère principale de respecter une architecture trois tiers.
Si je comprends bien cette notion, une architecture trois tiers comporte une vue, des contrôleurs, un modèle de données, toute indépendante les unes des autres.
La vue : Interface développé par le biais de Swing
Les contrôleurs : Les classes métiers et toutes les classes nécessaire à la manipulation de données.
Le modèle de données : La base de données.

La persistance des données se réalise grâce à l'aide de JPA.
Pour alimenter ma vue, des JTables sont utilisés pour afficher les données métiers. J'utilise des modèles de tables héritant de DefaultTableModel.
Les Jtables sont construites à partir de mon modèle de tables. Ces modèles comportent des List d'objets métiers afin d'assurer la cohérence des données.
Pour récupérer des données Métiers dans mon modèle de table, j'utilise un contrôleur que j’appellerai MetierManager (un pour chacune des classes Métiers) qui vont directement récupérer les données par le biais de MetierDao.

Afin d'alimenter le logiciel en données, j'aimerai que l'utilisateur puisse cliquer sur un bouton "+" afin de créer une ligne vide dans le tableau, qu'il puisse l'éditer, et valider afin de rendre persistante la donnée.
Mes questions sont les suivantes : ai-je bien saisi le concept d'architecture trois-tiers, et est-ce que l'architecture que je propose est conforme à celle-ci.
Je viens à vous car je ne suis pas sur de mon ajout de ligne vide via "addElement" en effet, je ne créé par directement un objet Metier dans mon Modèl de Table, mais la methode fait bien appel à une méthode retournant un objet vide de type Métier.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
public class CompartimentManager {
 
 
	public static Compartiment createTempCompartiment() {
		return new Compartiment();
	}
 
	public static Compartiment loadCompartiment(int uid) {
		return CompartimentDao.load(uid);
 
	}
 
	public static List<Compartiment> loadAllCompartiment() {
		return CompartimentDao.loadAll();
	}
 
}
 
 
 
 
public class CompartimentTableModel extends EscrimTableModel {
	private List<Compartiment> listeCompartiment = CompartimentManager
			.loadAllCompartiment();
	private String[] CompartimentColumnName = { "", "Nom", "Hauteur",
			"Longueur", "Largeur", "Volume", "Poids", "uid" };
 
	public CompartimentTableModel() {
		listeCompartiment = CompartimentManager.loadAllCompartiment();
	}
 
	@Override
	public String getColumnName(int columnIndex) {
		return CompartimentColumnName[columnIndex];
	}
 
	@Override
	public int getRowCount() {
		if (listeCompartiment != null) {
			return listeCompartiment.size();
		} else {
			return 0;
		}
	}
 
	@Override
	public int getColumnCount() {
		return 8;
	}
 
	@Override
	public Object getValueAt(int rowIndex, int columnIndex) {
		Compartiment compartiment = listeCompartiment.get(rowIndex);
		switch (columnIndex) {
		case 0:
			return null;
		case 1:
			return compartiment.getNom();
		case 2:
			return compartiment.getHauteur();
		case 3:
			return compartiment.getLongueur();
		case 4:
			return compartiment.getLargeur();
		case 5:
			return compartiment.getVolume();
		case 6:
			return compartiment.getPoids();
		case 7:
			return compartiment.getUid();
		}
		return null;
	}
 
	@Override
	public Class<?> getColumnClass(int columnIndex) {
		switch (columnIndex) {
		case 0:
			return String.class;
		case 1:
			return String.class;
		case 2:
			return Float.class;
		case 3:
			return Float.class;
		case 4:
			return Float.class;
		case 5:
			return Float.class;
		case 6:
			return Float.class;
		case 7:
			return Integer.class;
		}
		return null;
	}
 
	public void addElement() {
		listeCompartiment.add(0, CompartimentManager.createTempCompartiment());
		fireTableRowsInserted(0, getRowCount());
	}
}

Tout n'est pas encore implémenter, et j'ai besoin d'avis plus expert que le mien sur la question pour avancer. Merci d'avance pour vos réponses.

Fayne

[autran]

je suis loin d'être un expert du "n tier"
mais je te repondrai que swing integre dejà le pardigme MVC donc je mettrai plutot :
vue controleur : SWING
modele : tes objets metier en java (POJO)
données : JPA + base de donnée

[Fayne38]

Merci de prendre le temps de me répondre.
Lorsque tu parles de contrôleur, tu parles de contrôleurs de l'IHM qui seraient dans mon cas les modèles de tables, ou cela intègre-t-il les contrôleurs pour les classes Métiers ?

[joel.drigo]

Salut,

Ce que tu décris est plus proche de ce qu'on appelle la structure MVC (Modèle-Vue-Controlleur) :

• La vue : présentation des données (ce que l'utilisateur voit)
• Le modèle : les données
• Le contrôleur : met à jour le modèle quand la vue change (quand l'utilisateur modifie des données), change les données du modèle en fonction des actions (de l'utilisateur ou autre)

En terme d'architecture application, on parle d'architecture n-tiers (ou multi-tiers, ou multi-couche), dont le 3-tiers est un cas particulier, le plus commun. Il s'agit d'une répartition des rôles entre divers logiciels sur un réseau, pour une même application. Le MVC et le multitiers se ressemblent, mais le MVC concerne l'architecture interne d'un logiciel (par exemple, l'élément présentation (le client) dans une architecture 3-tiers, sera lui même architecturé avec un MVC, afin de découpler les composants chargés d'afficher, de manipuler et de conserver en mémoire les données.

En terme d'architecture application 3-tiers, on retrouvera donc des éléments similaires à ceux d'un MVC :

• une couche présentation - un client lourd (RDA), ou léger (RIA), comme un client web s'exécutant dans un navigateur (la vue MVC)
• une couche métier (ou fonctionnelle) : des services permettant de manipuler les données dans le sens du métiers (par exemple, pour une application de gestion de stock, on aura un service "créer commande", "livrer commande", "inventaire du stock", etc...) (le contrôleur MVC)
• une couche persistance (pour stocker les données), comme une base de données par exemple (le modèle MVC)

On retrouve la similarité pour les liens entre les parties :

• vue <-> contrôleur <-> modèle
• présentation <-> métier <-> données

Dans le MVC, la vue écoute aussi le modèle directement pour se mettre à jour (motif observeur/observé), ce qui n'est pas le cas habituellement pour une architecture n-tiers à base de données, où un autre module se chargera éventuellement de ça (un système de messages, type JMS ou Active-MQ), mais essentiellement pour des raisons techniques (pour les couches de persitences type JPA, je ne saurais dire, je ne connais absolument pas ce domaine).



Tu peux regarder d'une part ce tutoriel Développez sur l'architecture n-tiers : http://alwin.developpez.com/articles...i-multi-tiers/, et d'autre part l'article wikipedia sur le 3-tiers.

[Fayne38]

Merci pour ces précisions bien détaillées !
Si je cherche à vulgariser tes propos, afin de m'assurer la compréhension de ton post, il est difficile de parler d'architecture trois tiers lorsque l'on parle d'une application sous forme de client lourd de type CRUD ? Ce dernier serait plus un tier à proprement parler, un second serait la partie base de données gérées par un SGBDR.

J'ai réalisé de nombreuses recherches sur l'architecture trois tiers et je remarque une présence importante de documentation concernant sa théorie, mais beaucoup moins concernant son application direct.
De plus, nos professeurs nous ont indiqué les outils Swing pour l'IHM et JPA/ou un simple connecteur JDBC, pour la persistance des données. Et si je suis les dire de Kevinternet, Swing est clairement orienté pour une architecture MVC, le choix du framework n'était alors peut-être pas judicieux ?

[autran]

De plus, nos professeurs nous ont indiqué les outils Swing pour l'IHM et JPA/ou un simple connecteur JDBC, pour la persistance des données. Et si je suis les dire de Kevinternet, Swing est clairement orienté pour une architecture MVC, le choix du framework n'était alors peut-être pas judicieux ?

non je suis parti de l'hypothese que tu utilisais Swing et je te dis qu'il implemente le MVC2 au sens de présentation. il ne te reste plus alors qu'a gerer la persistence entre tes objets metier en java et la base de données.

pour les tier ca n'a rien a voir avec 1/3 c'est un mot americain qui signifie couches. tu peux donc très bien faire du 2 tier ou du 4 tier. pour toi, tu serais en 3 tier avec plus precisemment :

• presentation : MVC Swing
• metier : POJO
• données : JPA + base de donnée

du 4 tier serait par exemple

• présentation
• service
• metier
• donnnées

Kevin,