J'aimerais avoir votre avis sur un de mes projets.
Voilà je dois développer une application qui s'articulera autour d'un IHM et
d'une base de données MySQL.
Ma question : comment dois je procéder ? par au niveau code mais au niveau
structure ?
Dois je définir 3 objets : un objet représenant l'IHM, un autre permettant
la manipulation de la base de données et enfin un dernier liant les 2 autres
?
Est ce que 3 objets c'est trop ; 2 c'est largement suffisants ? ou bien un
objet unique ...?
Si vous êtes trouvé dans des cas similaires, ce serait sympa de les partager !
J'aimerais avoir votre avis sur un de mes projets.
Voilà je dois développer une application qui s'articulera autour d'un IHM et
d'une base de données MySQL.
Ma question : comment dois je procéder ? par au niveau code mais au niveau
structure ?
Dois je définir 3 objets : un objet représenant l'IHM, un autre permettant
la manipulation de la base de données et enfin un dernier liant les 2 autres
?
Est ce que 3 objets c'est trop ; 2 c'est largement suffisants ? ou bien un
objet unique ...?
Si vous êtes trouvé dans des cas similaires, ce serait sympa de les partager !
J'aimerais avoir votre avis sur un de mes projets.
Voilà je dois développer une application qui s'articulera autour d'un IHM et
d'une base de données MySQL.
Ma question : comment dois je procéder ? par au niveau code mais au niveau
structure ?
Dois je définir 3 objets : un objet représenant l'IHM, un autre permettant
la manipulation de la base de données et enfin un dernier liant les 2 autres
?
Est ce que 3 objets c'est trop ; 2 c'est largement suffisants ? ou bien un
objet unique ...?
Si vous êtes trouvé dans des cas similaires, ce serait sympa de les partager !
Bonsoir,
J'aimerais avoir votre avis sur un de mes projets.
Voilà je dois développer une application qui s'articulera autour d'un IHM et
d'une base de données MySQL.
Ma question : comment dois je procéder ? par au niveau code mais au niveau
structure ?
Dois je définir 3 objets : un objet représenant l'IHM, un autre permettant
la manipulation de la base de données et enfin un dernier liant les 2 autres
?
Est ce que 3 objets c'est trop ; 2 c'est largement suffisants ? ou bien un
objet unique ...?
Si vous êtes trouvé dans des cas similaires, ce serait sympa de les partager
!
Merci d'avance,
Mow
Bonsoir,
J'aimerais avoir votre avis sur un de mes projets.
Voilà je dois développer une application qui s'articulera autour d'un IHM et
d'une base de données MySQL.
Ma question : comment dois je procéder ? par au niveau code mais au niveau
structure ?
Dois je définir 3 objets : un objet représenant l'IHM, un autre permettant
la manipulation de la base de données et enfin un dernier liant les 2 autres
?
Est ce que 3 objets c'est trop ; 2 c'est largement suffisants ? ou bien un
objet unique ...?
Si vous êtes trouvé dans des cas similaires, ce serait sympa de les partager
!
Merci d'avance,
Mow
Bonsoir,
J'aimerais avoir votre avis sur un de mes projets.
Voilà je dois développer une application qui s'articulera autour d'un IHM et
d'une base de données MySQL.
Ma question : comment dois je procéder ? par au niveau code mais au niveau
structure ?
Dois je définir 3 objets : un objet représenant l'IHM, un autre permettant
la manipulation de la base de données et enfin un dernier liant les 2 autres
?
Est ce que 3 objets c'est trop ; 2 c'est largement suffisants ? ou bien un
objet unique ...?
Si vous êtes trouvé dans des cas similaires, ce serait sympa de les partager
!
Merci d'avance,
Mow
Bonjour,J'aimerais avoir votre avis sur un de mes projets.
Voilà je dois développer une application qui s'articulera autour d'un IHM et
d'une base de données MySQL.
Ma question : comment dois je procéder ? par au niveau code mais au niveau
structure ?
Dois je définir 3 objets : un objet représenant l'IHM, un autre permettant
la manipulation de la base de données et enfin un dernier liant les 2 autres
?
Est ce que 3 objets c'est trop ; 2 c'est largement suffisants ? ou bien un
objet unique ...?
Si vous êtes trouvé dans des cas similaires, ce serait sympa de les partager !
A mon avis, il te faut au moins deux objets pour avoir une architecture
propre (solution que je préconise dans le cahier du programmeur Java [1],
voir http://www.eteks.com/services/cahierjava1.html)
Un objet représente un enregistrement d'une table. La classe de cet objet se
chargera d'accéder à la base de données pour lire et écrire les données d'un
objet en base. Pour chaque table et donc des types de données différentes tu
crées des classes différentes.
L'autre objet représente la boîte de dialogue ou le panneau qui permet
d'éditer les données d'un objet de la classe précédente.
L'avantage de cette architecture est qu'elle permet de changer de type d'IHM
(par exemple pour utiliser des JSP à la place de Swing) sans avoir à
retoucher à la classe qui gère l'accès à la base de données.
Tu peux éventuellement utiliser un EJB entity pour réaliser la première
classe mais je ne pense pas que l'utilisation des EJB doit se faire de façon
systématique car ça revient à sortir toute la cavalerie quand on a juste
besoin d'un fantassin.
Cordialement
Bonjour,
J'aimerais avoir votre avis sur un de mes projets.
Voilà je dois développer une application qui s'articulera autour d'un IHM et
d'une base de données MySQL.
Ma question : comment dois je procéder ? par au niveau code mais au niveau
structure ?
Dois je définir 3 objets : un objet représenant l'IHM, un autre permettant
la manipulation de la base de données et enfin un dernier liant les 2 autres
?
Est ce que 3 objets c'est trop ; 2 c'est largement suffisants ? ou bien un
objet unique ...?
Si vous êtes trouvé dans des cas similaires, ce serait sympa de les partager !
A mon avis, il te faut au moins deux objets pour avoir une architecture
propre (solution que je préconise dans le cahier du programmeur Java [1],
voir http://www.eteks.com/services/cahierjava1.html)
Un objet représente un enregistrement d'une table. La classe de cet objet se
chargera d'accéder à la base de données pour lire et écrire les données d'un
objet en base. Pour chaque table et donc des types de données différentes tu
crées des classes différentes.
L'autre objet représente la boîte de dialogue ou le panneau qui permet
d'éditer les données d'un objet de la classe précédente.
L'avantage de cette architecture est qu'elle permet de changer de type d'IHM
(par exemple pour utiliser des JSP à la place de Swing) sans avoir à
retoucher à la classe qui gère l'accès à la base de données.
Tu peux éventuellement utiliser un EJB entity pour réaliser la première
classe mais je ne pense pas que l'utilisation des EJB doit se faire de façon
systématique car ça revient à sortir toute la cavalerie quand on a juste
besoin d'un fantassin.
Cordialement
Bonjour,J'aimerais avoir votre avis sur un de mes projets.
Voilà je dois développer une application qui s'articulera autour d'un IHM et
d'une base de données MySQL.
Ma question : comment dois je procéder ? par au niveau code mais au niveau
structure ?
Dois je définir 3 objets : un objet représenant l'IHM, un autre permettant
la manipulation de la base de données et enfin un dernier liant les 2 autres
?
Est ce que 3 objets c'est trop ; 2 c'est largement suffisants ? ou bien un
objet unique ...?
Si vous êtes trouvé dans des cas similaires, ce serait sympa de les partager !
A mon avis, il te faut au moins deux objets pour avoir une architecture
propre (solution que je préconise dans le cahier du programmeur Java [1],
voir http://www.eteks.com/services/cahierjava1.html)
Un objet représente un enregistrement d'une table. La classe de cet objet se
chargera d'accéder à la base de données pour lire et écrire les données d'un
objet en base. Pour chaque table et donc des types de données différentes tu
crées des classes différentes.
L'autre objet représente la boîte de dialogue ou le panneau qui permet
d'éditer les données d'un objet de la classe précédente.
L'avantage de cette architecture est qu'elle permet de changer de type d'IHM
(par exemple pour utiliser des JSP à la place de Swing) sans avoir à
retoucher à la classe qui gère l'accès à la base de données.
Tu peux éventuellement utiliser un EJB entity pour réaliser la première
classe mais je ne pense pas que l'utilisation des EJB doit se faire de façon
systématique car ça revient à sortir toute la cavalerie quand on a juste
besoin d'un fantassin.
Cordialement
Je trouve que laisser à une class métier le soin de s'enregistrer ou
de lire des donnés en base à tendance à complexifier le code de la
partie logique de l'application.
Code qui à mon avis doit être le plus simple possible au moins
concernant les beans.
Je trouve que laisser à une class métier le soin de s'enregistrer ou
de lire des donnés en base à tendance à complexifier le code de la
partie logique de l'application.
Code qui à mon avis doit être le plus simple possible au moins
concernant les beans.
Je trouve que laisser à une class métier le soin de s'enregistrer ou
de lire des donnés en base à tendance à complexifier le code de la
partie logique de l'application.
Code qui à mon avis doit être le plus simple possible au moins
concernant les beans.
Je trouve que laisser à une class métier le soin de s'enregistrer ou
de lire des donnés en base à tendance à complexifier le code de la
partie logique de l'application.
Code qui à mon avis doit être le plus simple possible au moins
concernant les beans.
Captainpaf, je ne cherches surtout pas à lancer un débat sans fin sur
l'avantage de tel ou tel design pattern. Je suis du genre pragmatique et je
pense qu'il vaut mieux mettre en oeuvre un modèle objet simple avant de
d'essayer un modèle dont les concepts ne sont pas encore assimilés.
Tout dépend à mon sens du niveau de connaissances en Java / Programmation /
Design Patterns du développeur... Utiliser correctement un modèle MVC quand
on vient d'apprendre Java me paraît illusoire, pareil pour les EJBs.
Une solution avec deux classes, l'une de type JavaBeans pour le stockage des
données et l'accès au SGBD, l'autre pour la gestion de la saisie dans l'IHM
s'explique beaucoup plus simplement car un débutant peut comprendre qu'il
peut avoir à exposer ses objets dans différents type d'IHM...
Donc Mow, si tu es une bête en programmation n'hésite pas à te lancer dans
un modèle MVC. Si tu as appris Java il y a deux mois, ne te lance pas dans
un modèle objet trop complexe tu risque de t'emmêler les pieds dans le
tapis.
Cordialement
Je trouve que laisser à une class métier le soin de s'enregistrer ou
de lire des donnés en base à tendance à complexifier le code de la
partie logique de l'application.
Code qui à mon avis doit être le plus simple possible au moins
concernant les beans.
Captainpaf, je ne cherches surtout pas à lancer un débat sans fin sur
l'avantage de tel ou tel design pattern. Je suis du genre pragmatique et je
pense qu'il vaut mieux mettre en oeuvre un modèle objet simple avant de
d'essayer un modèle dont les concepts ne sont pas encore assimilés.
Tout dépend à mon sens du niveau de connaissances en Java / Programmation /
Design Patterns du développeur... Utiliser correctement un modèle MVC quand
on vient d'apprendre Java me paraît illusoire, pareil pour les EJBs.
Une solution avec deux classes, l'une de type JavaBeans pour le stockage des
données et l'accès au SGBD, l'autre pour la gestion de la saisie dans l'IHM
s'explique beaucoup plus simplement car un débutant peut comprendre qu'il
peut avoir à exposer ses objets dans différents type d'IHM...
Donc Mow, si tu es une bête en programmation n'hésite pas à te lancer dans
un modèle MVC. Si tu as appris Java il y a deux mois, ne te lance pas dans
un modèle objet trop complexe tu risque de t'emmêler les pieds dans le
tapis.
Cordialement
Je trouve que laisser à une class métier le soin de s'enregistrer ou
de lire des donnés en base à tendance à complexifier le code de la
partie logique de l'application.
Code qui à mon avis doit être le plus simple possible au moins
concernant les beans.
Captainpaf, je ne cherches surtout pas à lancer un débat sans fin sur
l'avantage de tel ou tel design pattern. Je suis du genre pragmatique et je
pense qu'il vaut mieux mettre en oeuvre un modèle objet simple avant de
d'essayer un modèle dont les concepts ne sont pas encore assimilés.
Tout dépend à mon sens du niveau de connaissances en Java / Programmation /
Design Patterns du développeur... Utiliser correctement un modèle MVC quand
on vient d'apprendre Java me paraît illusoire, pareil pour les EJBs.
Une solution avec deux classes, l'une de type JavaBeans pour le stockage des
données et l'accès au SGBD, l'autre pour la gestion de la saisie dans l'IHM
s'explique beaucoup plus simplement car un débutant peut comprendre qu'il
peut avoir à exposer ses objets dans différents type d'IHM...
Donc Mow, si tu es une bête en programmation n'hésite pas à te lancer dans
un modèle MVC. Si tu as appris Java il y a deux mois, ne te lance pas dans
un modèle objet trop complexe tu risque de t'emmêler les pieds dans le
tapis.
Cordialement
Le Thu, 23 Oct 2003 13:07:23 +0200, Emmanuel PuybaretJe trouve que laisser à une class métier le soin de s'enregistrer ou
de lire des donnés en base à tendance à complexifier le code de la
partie logique de l'application.
Code qui à mon avis doit être le plus simple possible au moins
concernant les beans.
Captainpaf, je ne cherches surtout pas à lancer un débat sans fin sur
l'avantage de tel ou tel design pattern. Je suis du genre pragmatique
Le Thu, 23 Oct 2003 13:07:23 +0200, Emmanuel Puybaret
Je trouve que laisser à une class métier le soin de s'enregistrer ou
de lire des donnés en base à tendance à complexifier le code de la
partie logique de l'application.
Code qui à mon avis doit être le plus simple possible au moins
concernant les beans.
Captainpaf, je ne cherches surtout pas à lancer un débat sans fin sur
l'avantage de tel ou tel design pattern. Je suis du genre pragmatique
Le Thu, 23 Oct 2003 13:07:23 +0200, Emmanuel PuybaretJe trouve que laisser à une class métier le soin de s'enregistrer ou
de lire des donnés en base à tendance à complexifier le code de la
partie logique de l'application.
Code qui à mon avis doit être le plus simple possible au moins
concernant les beans.
Captainpaf, je ne cherches surtout pas à lancer un débat sans fin sur
l'avantage de tel ou tel design pattern. Je suis du genre pragmatique
On Thu, 23 Oct 2003 13:33:42 +0200, captainpaf wrote:Le Thu, 23 Oct 2003 13:07:23 +0200, Emmanuel PuybaretJe trouve que laisser à une class métier le soin de s'enregistrer ou
de lire des donnés en base à tendance à complexifier le code de la
partie logique de l'application.
Code qui à mon avis doit être le plus simple possible au moins
concernant les beans.
Captainpaf, je ne cherches surtout pas à lancer un débat sans fin sur
l'avantage de tel ou tel design pattern. Je suis du genre pragmatique
je suis moi aussi d'accord avec emmanuel sur cet aspect "pragmatique", par
contre je n'arrive pas bien a voir en quoi l'utilisation d'un modèle MVC
va séparer la partie "gestion de la base" de l'objet métier...? pour moi
les deux ont leur place dans le modèle, mais je n'ai peut etre pas encore
complétement assimilé le concept MVC ;-)
joe
On Thu, 23 Oct 2003 13:33:42 +0200, captainpaf wrote:
Le Thu, 23 Oct 2003 13:07:23 +0200, Emmanuel Puybaret
Je trouve que laisser à une class métier le soin de s'enregistrer ou
de lire des donnés en base à tendance à complexifier le code de la
partie logique de l'application.
Code qui à mon avis doit être le plus simple possible au moins
concernant les beans.
Captainpaf, je ne cherches surtout pas à lancer un débat sans fin sur
l'avantage de tel ou tel design pattern. Je suis du genre pragmatique
je suis moi aussi d'accord avec emmanuel sur cet aspect "pragmatique", par
contre je n'arrive pas bien a voir en quoi l'utilisation d'un modèle MVC
va séparer la partie "gestion de la base" de l'objet métier...? pour moi
les deux ont leur place dans le modèle, mais je n'ai peut etre pas encore
complétement assimilé le concept MVC ;-)
joe
On Thu, 23 Oct 2003 13:33:42 +0200, captainpaf wrote:Le Thu, 23 Oct 2003 13:07:23 +0200, Emmanuel PuybaretJe trouve que laisser à une class métier le soin de s'enregistrer ou
de lire des donnés en base à tendance à complexifier le code de la
partie logique de l'application.
Code qui à mon avis doit être le plus simple possible au moins
concernant les beans.
Captainpaf, je ne cherches surtout pas à lancer un débat sans fin sur
l'avantage de tel ou tel design pattern. Je suis du genre pragmatique
je suis moi aussi d'accord avec emmanuel sur cet aspect "pragmatique", par
contre je n'arrive pas bien a voir en quoi l'utilisation d'un modèle MVC
va séparer la partie "gestion de la base" de l'objet métier...? pour moi
les deux ont leur place dans le modèle, mais je n'ai peut etre pas encore
complétement assimilé le concept MVC ;-)
joe
On Thu, 23 Oct 2003 13:33:42 +0200, captainpaf wrote:Le Thu, 23 Oct 2003 13:07:23 +0200, Emmanuel PuybaretJe trouve que laisser à une class métier le soin de s'enregistrer ou
de lire des donnés en base à tendance à complexifier le code de la
partie logique de l'application.
Code qui à mon avis doit être le plus simple possible au moins
concernant les beans.
Captainpaf, je ne cherches surtout pas à lancer un débat sans fin sur
l'avantage de tel ou tel design pattern. Je suis du genre pragmatique
je suis moi aussi d'accord avec emmanuel sur cet aspect "pragmatique", par
contre je n'arrive pas bien a voir en quoi l'utilisation d'un modèle MVC
va séparer la partie "gestion de la base" de l'objet métier...? pour moi
les deux ont leur place dans le modèle, mais je n'ai peut etre pas encore
complétement assimilé le concept MVC ;-)
joe
On Thu, 23 Oct 2003 13:33:42 +0200, captainpaf wrote:
Le Thu, 23 Oct 2003 13:07:23 +0200, Emmanuel Puybaret
Je trouve que laisser à une class métier le soin de s'enregistrer ou
de lire des donnés en base à tendance à complexifier le code de la
partie logique de l'application.
Code qui à mon avis doit être le plus simple possible au moins
concernant les beans.
Captainpaf, je ne cherches surtout pas à lancer un débat sans fin sur
l'avantage de tel ou tel design pattern. Je suis du genre pragmatique
je suis moi aussi d'accord avec emmanuel sur cet aspect "pragmatique", par
contre je n'arrive pas bien a voir en quoi l'utilisation d'un modèle MVC
va séparer la partie "gestion de la base" de l'objet métier...? pour moi
les deux ont leur place dans le modèle, mais je n'ai peut etre pas encore
complétement assimilé le concept MVC ;-)
joe
On Thu, 23 Oct 2003 13:33:42 +0200, captainpaf wrote:Le Thu, 23 Oct 2003 13:07:23 +0200, Emmanuel PuybaretJe trouve que laisser à une class métier le soin de s'enregistrer ou
de lire des donnés en base à tendance à complexifier le code de la
partie logique de l'application.
Code qui à mon avis doit être le plus simple possible au moins
concernant les beans.
Captainpaf, je ne cherches surtout pas à lancer un débat sans fin sur
l'avantage de tel ou tel design pattern. Je suis du genre pragmatique
je suis moi aussi d'accord avec emmanuel sur cet aspect "pragmatique", par
contre je n'arrive pas bien a voir en quoi l'utilisation d'un modèle MVC
va séparer la partie "gestion de la base" de l'objet métier...? pour moi
les deux ont leur place dans le modèle, mais je n'ai peut etre pas encore
complétement assimilé le concept MVC ;-)
joe
