Discussion :

[Estebane]

Bonjour tout le monde ^^


Je souhaiterais avoir des avis à propos de l'implémentation de mon projet

Celui ci s'organise selon 5 couches

La base de données :
MySQL, dont l'identification se fait via un user unique qui ne peut utiliser que les procédures stockées que j'ai réalisé
les tables quant à elles respectent la 3 ième forme normale

La Couche DAO (Data Tranfert Object) :
C'est dans cette couche que sont exécutées les procédures stockées
On ne peut directement accéder à cette couche, pour y accéder il faut utiliser une Abstract factory qui renvoit des Interfaces DAO qui renvoit les méthodes...
La couche DAO renvoit des IDTO(Interface Data Tranfert Object) composé uniquement de gets
La couche DAO ne connait que les IDTO.

La couche BO (Bussines Object)
Elle contient la logique métier, ne vérifie à aucun moment si un objet est null ou "" etc...
Cette couche se charge également de cloner des objets lors de la modification de ceux-ci.
Elle est la seule à pouvoir faire appel à l 'Abstract Factory pour pouvoir utiliser les Interfaces DAO.
La couche BO ne transmet aux Interfaces DAO que des IDTO
La couche BO ne connait que des IDTO et les IDAO via la factory


La couche Use cases
cette couche atypique checke si les champs sont nulls, "" ,s'ils ne dépassent pas x carctères, si les chiffres ne sont par exemple pas négatifs. etc...
Elle renvoit des Interfaces BO qui ne disposent que de gets
On ne peut directement accéder àux couches uses case, pour y accéder il faut utiliser une Abstract factory qui renvoit des Interfaces Uses case qui renvoit les méthodes...


La couche servlet
Cette couche fait appel via une factory aux interfaces use cases
cette couche s'occupe des liens, redirection des pages jsp via spring-mvc.
elle vérifie également si l'objet utilisateur est dans l'objet session



A savoir aussi qu'en créant ma base de données j'ai déclaré des contraintes uniques(nom, prénom ,date de naissance), défini des champs qui ne peuvent être null ainsi que des limitations quant aux nombres de caractères que peuvent contenir chaques champs.
Ce qui fait évidemment doublon avec ma couche uses case, mais mon petit doigt me dit qu'il vaut mieux être un peu parano ^^
Et puis, avec mysql je ne peux personaliser les erreurs(sauf sur la dernière version non officiel qui a été retiré d'ailleur), donc lorsque j'ai une erreur de champs trop long,je ne peux savoir sur lequel vu que le code erreur est générique



Pour l'instant il existe deux types d'utilisateurs, bibliothécaire et administrateur, je vérifie donc dans chaque servlet si l'objet utilisateur existe dans la session
dans le cas contraire je renvoie à la page de login.
si l'adhérent est déjà logué sur un autre pc, je le délogue automatiquement de ce pc et il se logue normalement sur le nouveau pc de manière transparante.

Je pense que je devrai également par la suite encoder toutes mes méthodes dans ma base de données pour ensuite pouvoir vérifier dans chaque méthode java si celle-ci peut s'excecuter ou non

j'avoue ne pas avoir d'idée, j'essaie de respecter une architecture propre, alors je ne sais pas où je devrais faire ces tests de sécurité, dans quels couches ? et surtout pourquoi ?

merci de m'éclairer.


ps : je peux également metre mon code à disposition de qui veut ^^

[BugFactory]

Typiquement, la sécurité est considérée comme une couche supplémentaire, au dessus des autres.

Plutôt que de faire le test dans chaque servlet, vous devriez utiliser un filtre. Voici quelques documents sur les filtres :
http://www.j2ee.me/products/servlet/Filters.html
http://javaboutique.internet.com/tut...rvlet_Filters/

Bon courage.

[nrichand]

C'est bien, mais est ce vraiment adapté à la taille de ton projet?
D'après ta description je trouve que ça fait un peu usine à gaz.
Ton architecture t'apporte-t-elle suffisamment par rapport à la complexité engendrée?

[tchize_]

C'est bien, mais est ce vraiment adapté à la taille de ton projet?
D'après ta description je trouve que ça fait un peu usine à gaz.
Ton architecture t'apporte-t-elle suffisamment par rapport à la complexité engendrée?

Je me pose la meme question. Tu multiplie les couche pour une application qui, a vue de nez, est très petite. Ok, si il s'agit d'un grosse application avec de nombreuses regles buisness, plusieurs bases de donnée et de nombreux utilisateur, ca se justifie. Mais il si s'agit d'une petite application 2 administrateurs et 10 users, tu perd beaucoup de temps à faire de l'overengineering. Sans compter que le moindre changement demandé par le client risque d'impacter toutes les couche. Je pense franchement que les couche buisness / use case peuvent etre fusionnée. Probablement même en incluant l'accès à la database.

De plus, si tu transfère des objet différents entre chaque couche, tu va passer un temps dingue à faire du code qui ne fait que transférer des données d'un objet à l'autre.