Discussion :

[Invité]

Bonjour,

Je me suis intéressé à l'architecture multicouches pour la réalisation d'une application mais il subsiste quelques questions.

La communication entre la couche présentation et métier est (si j'ai bien compris) effectuée au moyen de DTO (Data Transfert Object) qui sont de simples structures de données.

Qui doit s'assurer que les données sont valides ?

Dans les applications Web MVC, il y a moyen d’annoter les modèles ou d'utiliser ModelState pour le ModelBinder (mais celà requiert de référencer System.Web.Mvc ce qui est à mon sens illogique pour la couche métier).

Faut-il que la validation se fasse sur la couche métier et signaler les erreurs avec la levées d'exceptions qui seraient traitées par la couche présentation ?
Ou faut-il faire une première passe dans la couche présentation (au moyen des outils que proposent ASP.NET MVC) puis une seconde dans la couche métier ?

Si quelqu'un pouvait m'éclairer j'en serais ravi.

Merci :-)

[Nadinette]

Salut,

J'ai trouvé ça : http://innovacallframework.codeplex.com/

Je n'ai pas eu le temps de le tester mais à priori, ça a été développé par une boite Française, c'est du MVC 4 et du multicouches.
J'ai un peu regardé, c'est du lourd... D’ailleurs, je n'ai certainement pas compris toutes les subtilités.

Ca pourrait peut-être répondre à tes attentes ou à une partie de tes questions.

A pluche

[Nadinette]

Salut,

Je viens d'acheter le Programmez du mois de décembre, il y a un article sur le Framework Innovacall.

Bon reveillon

[plouiserre]

Dans ta couche présentation tu as une partie model.
Pour moi dans ton architecture seule la partie model soit être valides par rapport aux données saisies par l'utilisateur.
En effet la couche métier ne se préoccupe pas de ce que saisit l'utilisateur.

[Nadinette]

Salut, tu réponds à qui ?

[BenoitM]

Dans ta couche présentation tu as une partie model.
Pour moi dans ton architecture seule la partie model soit être valides par rapport aux données saisies par l'utilisateur.
En effet la couche métier ne se préoccupe pas de ce que saisit l'utilisateur.

Euh c'est du n'importe quoi ca
La couche metier peut et doit faire des vérifications.

Part contre elle peut se basé sur le modele pour faire une partie de ses vérifications.

Exemple bateau :
La classe Etudiant.
Le modèle vérifie que le nom, prenom date de naissance sont bien remplis.
Dans la méthode CreerEtudiant, tu vérifieras que le le model est correcte.
Dans la méthode InscriptionAUnCours,tu vérifiras que l'etudiant n'a pas plus de 18 ans .


Sans compter que tes données peuvent venir de n'importe qui WebService , donc si ta couche métier ne fait pas de vérification tu peux insérer des données corrompues

[Nadinette]

Salut,

Ben si tu as correctement gaulé ton modèle, la validation est déterminée par les annotations.

La validation des champs ne permet que de vérifier la compatibilité des données saisies avec les données attendues.

La validation dans la couche métier est plutôt limité à des règles métier mais on peut tester sir le model est valide côté serveur.

A bientôt

[plouiserre]

Euh c'est du n'importe quoi ca
La couche metier peut et doit faire des vérifications.

Part contre elle peut se basé sur le modele pour faire une partie de ses vérifications.

Exemple bateau :
La classe Etudiant.
Le modèle vérifie que le nom, prenom date de naissance sont bien remplis.
Dans la méthode CreerEtudiant, tu vérifieras que le le model est correcte.
Dans la méthode InscriptionAUnCours,tu vérifiras que l'etudiant n'a pas plus de 18 ans .


Sans compter que tes données peuvent venir de n'importe qui WebService , donc si ta couche métier ne fait pas de vérification tu peux insérer des données corrompues

Désolé je me suis mal exprimé.
Bien sur que le métier doit vérifier les données.
J'avais oublié de préciser sur le "format" des données je le voyais vérifier dans la partie présentation tandis que si la saisie était conforme au métier c'était vérifié dans la couche métier.

[Immobilis]

Salut

Euh c'est du n'importe quoi ca
La couche metier peut et doit faire des vérifications.

Ca se discute. Les contrôles de "surface" sont très importants pour que l'interface soit conviviale (rapide, explicite).

Certain modèles (POCO) intègre directement la validation des valeurs de leurs propriétés: http://skalp.developpez.com/traducti...e-dto-et-poco/

Est-ce que la couche métier doit vérifier une saisie? Pas forcement. C'est important si cela peut faire planter un processus par la suite. Par exemple, l'envoi d'un mail. Toutefois, si cela a déjà été contrôlé en surface est-il nécessaire de refaire cette vérification?

A mon avis, il faut faire un contrôle en fonction des responsabilités. Si il s'agit d'insérer simplement des données en base, ce pourrait être à la base de données de le faire. "Exemple bateau": une base de données cliente est alimentée par plusieurs interfaces (Web, Phone, Windows), le point commun entre tout ces canaux c'est la base de données. La dernière couche à même de vérifier qu'on a bien un email est la base de données.

Après, c'est une question d'architecture, de maîtrise, de sensibilité.

A+

[Nadinette]

Salut,

Pour ma part, lorsque l'interface est exposée à des risques de malveillance, je fais la double vérification.

Premièrement, l'unobstrusive validation garantie (sauf piratage par débugueur javascript) que les données envoyées par le submit sont conformes aux attentes du développeur.

Le second contrôle côté serveur est effectué juste avant l'injection en base. De ce fait, j'évite les soucis.

Si le modèle de données est correct, il ne pourra pas y avoir de problème sur une table seule. C'est lorsqu'il y a des jointures et en particulier des valeurs de clef que l'on transfère au client dans des hiddens qu'il faut faire attention.

On en revient au principe du viewstate mais, à mon gout on peut mieux maîtriser le processus avec MVC mais c'est plus difficile.

Bonne journée

[Immobilis]

Si le modèle de données est correct, il ne pourra pas y avoir de problème sur une table seule.

Tu peux préciser? Je comprend pas ce que tu veux dire par "sur une table seule".

C'est lorsqu'il y a des jointures et en particulier des valeurs de clef que l'on transfère au client dans des hiddens qu'il faut faire attention.

Tout dépend de ce qu'on veut vérifier.

Dans les applications Web MVC, il y a moyen d’annoter les modèles ou d'utiliser ModelState pour le ModelBinder (mais celà requiert de référencer System.Web.Mvc ce qui est à mon sens illogique pour la couche métier).

MVC est un pattern pour les IHM (pour le Web avec ASP.NET MVC). La couche métier à proprement parler ne devrait pas référencer ce namespace. Pour t'assurer que ta couche métier est interopérable, mets la dans un projet à part et fais la fonctionner sur une console.

A+

[Nadinette]

Tu peux préciser? Je comprend pas ce que tu veux dire par "sur une table seule".

Une table qui n'est pas en relation avec une autre...

[Immobilis]

Une table qui n'est pas en relation avec une autre...

Et pourquoi y aurait-il plus de problèmes sur des tables jointes que sur une table "seule"?

[Nadinette]

Imaginons un système multi-clients dont les données seraient rattachées au code client

Table client
Id
Nom

Table transactions
Id
FK_Client
...

Si tu crées un nouvel enregistrement en ne te basant que sur la clef étrangère que tu aurais passé dans un hidden, ce dernier peut être très facilement remplacé par une autre valeur.

Un utilisateur malveillant pourrait affecter une transaction à un autre client.

Dans le cas d'une consultation, un client pourrait consulter le compte d'un autre.

[Immobilis]

Sujet intéressant

Il faut faire la différence entre la validité de la valeur (est-ce que la valeur saisie correspond au type attendu par ma base?) et la "cohérence" du jeu de données. Dans le premier cas, le Framework fait le travail avec les objets typés. Dans le deuxième cas, c'est une question de sécurité. Un projet à lui seul.

En ASP.NET WebForm, le ViewState et le Framework permettent (dans une certaine mesure) de garantir les données entre l'aller et le retour. Assurement, il y a toujours une possibilité de "pirater" le ViewState.

En ASP.NET MVC, je ne sais pas comment cela est pris en charge. Le sujet est abordé en 2009 dans ce billet. Comment cela est-il géré dans les nouvelles versions de ce Framework? C'est une grosse faille.

Vérifier que les données n'ont pas été altérées est effectivement à placer dans un projet dédié. Je ne l'implémenterais probablement pas dans les contrôleurs.

Un utilisateur malveillant pourrait affecter une transaction à un autre client.

Tu veux dire que tu compares systématiquement la valeur de tes contrôles avec celle correspondante envoyé dans la page lors du premier affichage? S'agissant de la création d'un enregistrement associé à un utilisateur, je vois pas trop pourquoi l'id de l'utilisateur devrait figurer dans le formulaire. Puisqu'il y a eu une authentification, il faut affecter cette "transaction" à l'utilisateur authentifié dont les informations sont conservées sur le serveur. A moins que l'objet du formulaire soit d'affecter une transaction à un utilisateur dans une liste. Si tu travailles en HTTPS, il y a assez peu de chances pour que le contenu de ta requête soit altéré.

Dans le cas d'une consultation, un client pourrait consulter le compte d'un autre.

Effectivement, quand on ne vérifie pas qu'un identifiant passé dans l'url correspond bien à celle attendue on obtient ceci: http://www.lemonde.fr/technologies/a...76_651865.html

A+

[Nadinette]

Sujet intéressant
Tu veux dire que tu compares systématiquement la valeur de tes contrôles avec celle correspondante envoyé dans la page lors du premier affichage?

Moi non mais je l'ai déjà vu...

[Immobilis]

Moi non mais je l'ai déjà vu...

Je serais curieux de savoir sur quelle base cette stratégie est implémentée.

[Immobilis]

Qui doit s'assurer que les données sont valides ?

Dans les applications Web MVC, il y a moyen d’annoter les modèles ou d'utiliser ModelState pour le ModelBinder (mais celà requiert de référencer System.Web.Mvc ce qui est à mon sens illogique pour la couche métier).

Faut-il que la validation se fasse sur la couche métier et signaler les erreurs avec la levées d'exceptions qui seraient traitées par la couche présentation ?
Ou faut-il faire une première passe dans la couche présentation (au moyen des outils que proposent ASP.NET MVC) puis une seconde dans la couche métier ?

C'est assez bien décrit ici finalement: http://dotnet.developpez.com/mvc/mvc...vice-layer/#LE

[tchize_]

Salut,

J'ai trouvé ça : http://innovacallframework.codeplex.com/

Salut,

Je viens d'acheter le Programmez du mois de décembre, il y a un article sur le Framework Innovacall.

Bon reveillon

Désolé de relever ça aussi tard, mais ce framework est assez inconnu au bataillon. Et je ne prendrais surtout pas trop pour argent comptant le fait que ce soit publié dans le magazine programmez. Outre le fait qu'il faut une colonne complète dans le magazine juste pour énumérer toutes les couches de l'application, le fait que l'article aie été écrit par l'auteur même du framework le rapproche plus selon moi d'un article sponsorisé que d'un contenu éditorial neutre.