Architecture d'une application JEE

Citation:

---

Envoyé par Jimmy_

Le sujet fait débat certes, mais logique ou physique, si tu ne fais pas une isolation minimal entre ta présentation et tes données, via un quelconque mécanisme. On ne peut pas parler de n-tiers, ni de MVC, ni de rien du tout.
Ca sera juste un gros bouzin :mouarf: .

J'ai même vu dans mes audits, du jdbc en scriptlet dans les jsp. :aie:

---

Pour la dernière remarque, on est typiquement dans le genre d'application PHP, de là à dire que c'est un gros bouzin, c'est un peu excessif... tout dépend de ce qu'on veut faire.
Pour une page à contenu dynamique, c'est très adapté (contrairement à l'architecture MVC, c'est comme si on voulait démolir un mûr avec un canon de 888mm :aie:)

Pour une application conséquente, par contre, ce pattern aide beaucoup...

Bonjour,

Je suis d'accord avec le Post de Obutterlin, qui a souvent d'ailleurs un avis judicieux.
Beaucoup de monde confond l'aspect N-tiers avec celui d'une architecture physique ( machine ).
Le N-tiers est un découpage logique, si en plus tu y introduis des services délocalisés (physique) cela est encore mieux. On colle pas le serveur d'application sur la machine qui héberge la base de donnée.

Pour ce qui est de ton analyse, tu dois nous prouver que chaque couche ou jar, war etc . pourrais fonctionner les uns indépendements des autres.
Bref ma couche authentification (un jar) peux être exportable sur un autre projet sans rien modifié, et cette réflexion pour chaque couche.

Dire que jdbc est une couche est un abus de langage, si tu as des requêtes dans tes servlets c'est donc mal construit.
Normalement on doit pouvoir interroger ton système de persistence sans savoir si c'est du SGBD, du fichier ou du ldap.
C'est la théorie, mais en pratique c'est mieux. car plus maintenable.

Dans les frameworks type, JSF tu es déjà en multicouche un template/ un bean manager (MVC), puis tu peux interroger des EJB qui mappent une couche services ( objet métiers ) qui interroge des objets JPA (qui mappe la base ou autre) bref on pourrais encore découpé. Mais si je remplace une couche par une autre ayant les mêmes signatures de méthodes, et l'application doit toujours fonctionner.

Souvent on expose des interfaces (pas de code)

Les designs patterns sont un bon moyen de comprendre.

Mais j'avoue il faut pratiquer et maintenir pour bien comprendre les affres du "tout dans le même fichier" (vue, base traitement) si si j'en voit encore.

Mais parfois c'est mieux, c'est souvent un compromis entre optimisation et architecture, rien n'est parfait, et à faire des couches de couches, cela devient parfois incompréhensible (code mort)
Bref il faut rester critique.


Olivier

Citation:

---

Envoyé par nathieb

... c'est souvent un compromis entre optimisation et architecture, rien n'est parfait, et à faire des couches de couches, cela devient parfois incompréhensible (code mort)
Bref il faut rester critique.

---

C'est également mon point de vue :ccool:

Il faut rester critique ET savoir s'arrêter à temps ! A force de théoriser, on ne livre plus d'application... :mouarf:

Bonjour,

Bonne conclusion !
:ccool: a force

olivier

D'accord, merci

Donc si c'est juste, je ferai mieux de dire que c'est une application 3-tiers utilisant la plateforme JEE ( je parlerai pas du pattern MVC), avec mon serveur qui alimente ma base de donnée
:ange:

Bonjour,

Oui.

Olivier