Discussion :

[TyeFromEzella]

bonjour,
je suis débutant en java et pour bien corsé l'affaire je me suis lancé dans une application assez complexe (pour moi ) : gestion d'un magasin (articles/clients/fournisseurs, etc ...) avec base de données MySQL.

j'avance pas mal mais je crois que j'ai qqs soucis dans l'architecture générale de mon programme...

Alors question :
je suis amené a gérer des articles donc j'ai créer une class Article pour pouvoir gérer UN article (reference, prix, fournisseur, etc...).

Code :

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

1
2
3
4
5
6
7
8
9
 
public class Article {
  public String reference;
  public Float prix;
  public Fournisseur fournisseur;
 
  public Float getPrix(){ ... }
  public Fournisseur getFournisseur() { ... }
}

Je suis amené aussi à afficher la liste de tous mes Article avec une fonction printAllItems().
Selon vous pour avoir une bonne architecture, faut il placer cette fonction dans ma class Article ou alors vaudrait il mieux la placer dans une class a part qui controlerai mes Article ?


je vous remercie d'avance

[Mister Nono]

printAllItems(List<L> liste) peut aussi imprimer toutes les listes qui lui sont passées en paramètre.

Comme cela cette méthode peut être déclarée en static et être appelée dans toutes tes applications pour toutes sortes de liste.

A+

[TyeFromEzella]

oui je suis daccord mais cela ne m'aide pas vraiment héhé

dans ton exemple si je veux afficher une Liste d'article encore faut il la créer qqpart...
et a quel endroit dois je la créer ? dans ma class Article ou autre part ?

merci de ta réponse

[elmor]

Est-ce que tu utilises un couche pour Mapper tes tables SQL dans des objets ?

Sinon, je te conseille de regarder le project hybernate et tu auras la réponse à ta question

Et en plus tu apprendras librairie super utilisée.

[TyeFromEzella]

non j'utilise rien pour BDD seulement des classes a moi ..
j'ai deja lus quelques trucs sur hibernate mais j'ai trouvé ça super compliqué alors j'ai préféré continuer à tout gérer moi même.
mais c'est vrai qu'avec la gestion de la BDD en plus c'est pas simple :s

[elmor]

Personnellement je trouve qu'il est dommage de réinventer la roue.
Le résultat risque d'être:
1) moins bon
2) moins performant
3) moins évolutif

Je suis d'accord, tu perdras du temps au début mais, tu verras, tu en gagneras pas mal ensuite.

Comme je le dis souvent "on n'a pas le temps de gagner du temps".

[Mister Nono]

Un outil comme Hibernate est un passage obligé pour gagner en qualité et en performance.

[TyeFromEzella]

haha va pour Hibernate alors !!!
Mais le problème de mon architecture (en dehors de la BDD) est toujours pas résolu ...

[sinok]

Un outil comme Hibernate est un passage obligé pour gagner en qualité et en performance.

Euuuuuhh

De une: Avant de toucher à Hibernate il faut avoir fait un tant soit peu de JDBC pour comprendre la philosophie java à ce niveau là, c'est largement préférable.

De deux: Hibernate impose des contraintes très fortes au niveau de la modélisation de la base de données, une fois sorti des chose basiques ça pêut devenir un sacré merdier.

De trois: hibernate a plus tendance à faire chuter les perfs par rapport aux mêmes développements effectués en jdbc pur.

Donc grosso modo Hibernate est un très bon outil mais de loin pas le saint graal. Il est merveilleusement adapté à certaines situations (pour un CRUD c'est du régal), par contre horrible pour d'autres.

Enfin voilà en ce qui concerne hibernate.

[Mister Nono]

Quand je parlais de "performance" je voulais dire "temps de réalisation de l'application".

Il va de soit, qu'en rajoutant une couche logicielle supplémentaire, les performances logicielles peuvent être diminuées. Bien que ce ne soit pas toujours le cas, car souvent des outils comme Hibernate rendre les applications plus optimisées que si nous le faisions personnellement.

Maintenant, il est bien de comprendre JDBC avant de passer sous Hibernate et par la suite à des constructions J2EE comme EJB.

A+

[tchize_]

De trois: hibernate a plus tendance à faire chuter les perfs par rapport aux mêmes développements effectués en jdbc pur.

T'as des références sur ce que t'avance là, parce que, des requetes sql générées par hibernate, j'en ai vu des tartines et elles m'ont toujours semblé bien plus performantes que ce que j'ai vu dans des code où les programmeurs faisaient manuellement leur requetes.

[unknow0]

Bonjour,

pour revenir au sujet:
Moi je ferais une class pour gerer la connection a la bdd (ou hibernate ca c'est a toi de voir )
une class pour les article (comme tu a fait )
et une class qui gerera les article

ps: pour ta class article si tu met les membre en public les accesseur ne serve pas.
ps2: met plutot les atribut en private avec des accesseur

[TyeFromEzella]

alors hibernate ou pas hibernate... pour l'instant je vais continuer sans.. c'est pas la gestion de la BDD qui me pose soucis pour le moment.

merci unknow0, je crois que je vais faire comme tu m'a dit.. je pense que c'est le mieux.
Par contre comme c'est une application graphique, j'ai une couche qui vient se rajouter par dessus tout ca mais je pense que je m'en sortirai en gardant le même shéma.

merci a tous pour vos réponses !
bonne fin de soirée

[millie]

Je suis amené aussi à afficher la liste de tous mes Article avec une fonction printAllItems()

Salut,

Que signifie "afficher la liste" pour toi.

En général, dans les applications avec base de données, les données métiers comme Article dispose juste de getter/setter et éventuellement (on va dire rarement) d'une méthode toString() qui sera plus utilisé pour afficher des traces dans la console (ce qui sert plus pour le débug/développement qu'autres choses).

En général, tu récupères de la base de données une collection d'Article (ou une liste ou un set), et c'est dans la partie de visualisation de générer la représentation de l'article car seule la vue sait comment on veut l'écrire.

Dans une application console, cela pourrait être des simples sorties sur System.out, dans une application Web, cela pourrait être la jsp qui s'occupe de parcourir la liste pour afficher les données dans un tableau par exemple, et dans une application Swing, cela se ferait au niveau de la génération de tes Frames.

Et concernant Hibernate/JDBC, on peut faire du mapping objet-relationnel en JDBC et avoir une architecture relativement bonne qui pourra éventuellement être modifié à l'avenir pour mettre de l'hibernate.

[pseudocode]

Je suis amené aussi à afficher la liste de tous mes Article avec une fonction printAllItems().
Selon vous pour avoir une bonne architecture, faut il placer cette fonction dans ma class Article ou alors vaudrait il mieux la placer dans une class a part qui controlerai mes Article ?

Comme je suppose que la fonction "printAllItems()" a pour objectif d'afficher tous les articles du magasin, alors il est logique de la placer dans une classe Magasin. non ?

[sinok]

Comme je suppose que la fonction "printAllItems()" a pour objectif d'afficher tous les articles du magasin, alors il est logique de la placer dans une classe Magasin. non ?

J'aurais même tendance à l'externaliser complètement dans une classe ayant pour but de faire uniquement de la présentation, et laisser les objets Produits et Magasins en tant que de beans sans plus. Cette classe ayant un magasin/un produit en tant que delegate.

[pseudocode]

J'aurais même tendance à l'externaliser complètement dans une classe ayant pour but de faire uniquement de la présentation, et laisser les objets Produits et Magasins en tant que de beans sans plus. Cette classe ayant un magasin/un produit en tant que delegate.

Mais si le PO compte utiliser un ORM, il sera effectivement plus simple de faire de simple beans, et de créer des delegate.

Mais vu qu'on est dans le forum "débuter", je proposais un simple découpage en responsabilité "métier" car c'est plus simple a appréhender.

[OButterlin]

Généralement, on utilise une classe par "entité" qui ne fait que représenter les données de l'entité ainsi que les références "utiles" d'un point de vue fonctionnel.
On fait ensuite une classe spécialisée (DAO) pour extraire ou manipuler les entités. Le CRUD (pour Create Read Update Delete) est une forme simple de DAO pour les opérations de base sur une entité.
D'un point de vue découpage, on aura donc des DAO plus ou moins complexes pour l'extraction des données et des CRUD pour l'aspect persistence le tout manipulant des entités.

Donc, dans ton cas, ta classe Article ne devrait que contenir les propriétés de l'article et éventuellement des listes d'objets liés à un article.
Tu devrais donc mettre ta méthode listAll() dans le CRUD alors que je mettrais une méthode list(String param1, Integer param2, ...) dans un DAO parce que là, c'est un besoin spécifique à un module particulier (peut-être).
Tu me suis ? Si je ne suis pas clair, n'hésite pas

A+

[TyeFromEzella]

waaa super ! merci à tous, je commence a y voir plus clair. En fait je crois que je connais la "théorie" (MVC et tout ca...) mais je n'arrive pas à le mettre en pratique...

@OButterlin :
je ne comprends pas la réelle différence entre CRUD et DAO puisque tu me dis que un CRUD est une forme de DAO....

et dans le cas de ma class Article la comment appellerais tu la classe qui contrôlerais/manipulerais mon entité Article ?


merci !! et bonne soirée à tous !

[OButterlin]

@OButterlin :
je ne comprends pas la réelle différence entre CRUD et DAO puisque tu me dis que un CRUD est une forme de DAO....

et dans le cas de ma class Article la comment appellerais tu la classe qui contrôlerais/manipulerais mon entité Article ?

Le CRUD est une DAO spéciale mais à usages multiples (dans une application) et/ou transversal.
Il s'occupe uniquement :
- de l'accès par la clé primaire de l'entité (findByPrimaryKey)
- l'accès à toutes les entités (listAll)
- la mise à jour
- la création
- la suppression

Dans une application, généralement, on n'accède pas aux données uniquement via une clé primaire ou la liste de tous les enregistrements.
En fonction des IHM, on utilise des filtres, des recherches par éléments associés, etc... C'est ce qu'on place dans les DAO (autre que CRUD, bien sûr).
Rien n'empêche de mettre des fonctions passerelles entre ces DAO et le CRUD.

Pour ta deuxième question, j'appellerais cette classe ArticleDAO ou ArticleService, un truc dans le genre...

A+