Bonjour, dans cet exemple d'application (http://www.cs.umanitoba.ca/
~eclipse/ClientBilling.zip) le but est de gérer une liste de clients et de
transactions associées à chacun d'entre eux.
L'auteur a choisi :
- de créer une classe client et une classe transaction, ne proposant
presque pas de traitements. Les données membres correspondent aux champs de
la base de données
- de construire l'application en 3 couches :
1) ApplicationUI : Interface utilisateur
2) ApplicationProc : Traitements
3) ApplicationDB : Accès SQL
Pour ce qui me concerne, je trouve que l'organisation de l'appli est assez
claire (la compréhension du code est simple preuve que le modèle doit être
bon) mais par contre je trouve que créer un classe Client ou Transaction
simplement pour rendre "objet" les données issues de la base génère
beaucoup de code (ici une table)...
En clair, dans DB au lieu d'avoir une méthode update(String nom,prenom,etc)
on a update(Client c)
Que pensez-vous de cette organisation ? Est-un bon modèle à réutiliser pour
débuter dans le monde de la programmation d'applications desktop Java ?
Même sur un projet un peu plus de complexité intermédiaire ? N'est-ce pas
trop lourd ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Lionel
Zouplaz wrote:
L'auteur a choisi :
- de créer une classe client et une classe transaction, ne proposant presque pas de traitements. Les données membres correspondent aux champs de la base de données - de construire l'application en 3 couches : 1) ApplicationUI : Interface utilisateur 2) ApplicationProc : Traitements 3) ApplicationDB : Accès SQL
Que pensez-vous de cette organisation ?
L'idée est bonne (MVC) mais sa mise en place est catastrophique dans le code cité en exemple.
1) Renseigne toi sur google sur les pattern MVC et DAO, écris ton propre système de persistance pour bien comprendre tout le fonctionnement de A à Z. 2) Ensuite jette tout ton code et utilise Hibernate. Evite d'utiliser directement à Hibernate, l'étape 1 t'apportera bcp de notions importantes.
Zouplaz wrote:
L'auteur a choisi :
- de créer une classe client et une classe transaction, ne proposant
presque pas de traitements. Les données membres correspondent aux
champs de la base de données
- de construire l'application en 3 couches :
1) ApplicationUI : Interface utilisateur
2) ApplicationProc : Traitements
3) ApplicationDB : Accès SQL
Que pensez-vous de cette organisation ?
L'idée est bonne (MVC) mais sa mise en place est catastrophique dans le code
cité en exemple.
1) Renseigne toi sur google sur les pattern MVC et DAO, écris ton propre
système de persistance pour bien comprendre tout le fonctionnement de A à Z.
2) Ensuite jette tout ton code et utilise Hibernate.
Evite d'utiliser directement à Hibernate, l'étape 1 t'apportera bcp de
notions importantes.
- de créer une classe client et une classe transaction, ne proposant presque pas de traitements. Les données membres correspondent aux champs de la base de données - de construire l'application en 3 couches : 1) ApplicationUI : Interface utilisateur 2) ApplicationProc : Traitements 3) ApplicationDB : Accès SQL
Que pensez-vous de cette organisation ?
L'idée est bonne (MVC) mais sa mise en place est catastrophique dans le code cité en exemple.
1) Renseigne toi sur google sur les pattern MVC et DAO, écris ton propre système de persistance pour bien comprendre tout le fonctionnement de A à Z. 2) Ensuite jette tout ton code et utilise Hibernate. Evite d'utiliser directement à Hibernate, l'étape 1 t'apportera bcp de notions importantes.
Zouplaz
Lionel - SPAMcoollATfreePOINTfr :
1) Renseigne toi sur google sur les pattern MVC et DAO, écris ton propre système de persistance pour bien comprendre tout le fonctionnement de A à Z.
N'est pas trop compliqué même si sans aller au bout de problème ? Un mini hibernate limité c'est possible à concevoir quand on débute ?
Lionel - SPAMcoollATfreePOINTfr :
1) Renseigne toi sur google sur les pattern MVC et DAO, écris ton
propre système de persistance pour bien comprendre tout le
fonctionnement de A à Z.
N'est pas trop compliqué même si sans aller au bout de problème ?
Un mini hibernate limité c'est possible à concevoir quand on débute ?
1) Renseigne toi sur google sur les pattern MVC et DAO, écris ton propre système de persistance pour bien comprendre tout le fonctionnement de A à Z.
N'est pas trop compliqué même si sans aller au bout de problème ? Un mini hibernate limité c'est possible à concevoir quand on débute ?
Lionel
Zouplaz wrote:
Lionel - SPAMcoollATfreePOINTfr :
1) Renseigne toi sur google sur les pattern MVC et DAO, écris ton propre système de persistance pour bien comprendre tout le fonctionnement de A à Z.
N'est pas trop compliqué même si sans aller au bout de problème ?
Non, ce n'est pas forcément complexe. Le but n'est pas d'obtenir l'architecture parfaite du premier coup, mais de progresser par étape en comprenant qu'écrire un peu plus de code à tel endroit permettra de gagner bcp ailleurs. Meme si tu n'as que deux tables, tu verras vite quelles sont les points faibles/points forts de ton archi. Je pense que c'est une étape importante, avant d'utiliser des outils tel qu'hibernate, pour comprendre ce qui se passe en dessous. Pense surtout évolutivité et réutilisabilité...
Un mini hibernate limité c'est possible à concevoir quand on débute ? Oui il est possible de concevoir un système de persistance simple plus ou
moins propre pour apprendre. La preuve, tu en as cité un en exemple. Base toi sur ce code: garde les bonnes idées (structure), évite les mauvaises (toute la partie requetes SQL).
Zouplaz wrote:
Lionel - SPAMcoollATfreePOINTfr :
1) Renseigne toi sur google sur les pattern MVC et DAO, écris ton
propre système de persistance pour bien comprendre tout le
fonctionnement de A à Z.
N'est pas trop compliqué même si sans aller au bout de problème ?
Non, ce n'est pas forcément complexe.
Le but n'est pas d'obtenir l'architecture parfaite du premier coup, mais de
progresser par étape en comprenant qu'écrire un peu plus de code à tel
endroit permettra de gagner bcp ailleurs.
Meme si tu n'as que deux tables, tu verras vite quelles sont les points
faibles/points forts de ton archi.
Je pense que c'est une étape importante, avant d'utiliser des outils tel
qu'hibernate, pour comprendre ce qui se passe en dessous.
Pense surtout évolutivité et réutilisabilité...
Un mini hibernate limité c'est possible à concevoir quand on débute ?
Oui il est possible de concevoir un système de persistance simple plus ou
moins propre pour apprendre.
La preuve, tu en as cité un en exemple.
Base toi sur ce code: garde les bonnes idées (structure), évite les
mauvaises (toute la partie requetes SQL).
1) Renseigne toi sur google sur les pattern MVC et DAO, écris ton propre système de persistance pour bien comprendre tout le fonctionnement de A à Z.
N'est pas trop compliqué même si sans aller au bout de problème ?
Non, ce n'est pas forcément complexe. Le but n'est pas d'obtenir l'architecture parfaite du premier coup, mais de progresser par étape en comprenant qu'écrire un peu plus de code à tel endroit permettra de gagner bcp ailleurs. Meme si tu n'as que deux tables, tu verras vite quelles sont les points faibles/points forts de ton archi. Je pense que c'est une étape importante, avant d'utiliser des outils tel qu'hibernate, pour comprendre ce qui se passe en dessous. Pense surtout évolutivité et réutilisabilité...
Un mini hibernate limité c'est possible à concevoir quand on débute ? Oui il est possible de concevoir un système de persistance simple plus ou
moins propre pour apprendre. La preuve, tu en as cité un en exemple. Base toi sur ce code: garde les bonnes idées (structure), évite les mauvaises (toute la partie requetes SQL).
