c'est la validation: est-ce du modèle? de la vue? les deux?
Là c'est plus un problème général à la programmation objet. Une pratique courante veut qu'un objet est responsable de son état et des informations qu'il contient.
Le minimum dans une application est que le modèle métier soit robuste : les informations doivent donc être validées dans le modèle. Y associer un ensemble de tests unitaires pour s'assurer qu'il n'y a pas de régressions.
Ensuite l'interface (vue/controlleur) doit dans l'idéal n'autoriser la saisie que d'information valides vis-à-vis du modèle. Un mask peut être appliqué par exemple côté client, tu peux également faire des vérifications dans le contrôleur, dans le pire des cas l'information non valide arrivera au modèle qui DOIT te lever une belle exception :)
Dans tous les cas, si tu veux te protéger de tentatives de hack SQL, c'est la classe manipulant la base de données qui s'occupe de faire la validation : elle est la seule censée connaître la couche d'accès aux données (ici une base de donnée), elle est donc la seule à savoir quels problèmes potentiels peuvent survenir.
[^] # Re: Quelques remarques en vrac
Posté par TImaniac (site web personnel) . En réponse au journal MVC avec ASP.NET. Évalué à 4.
http://msdn2.microsoft.com/en-US/library/c6zyy3s9(VS.80).asp(...)
c'est la validation: est-ce du modèle? de la vue? les deux?
Là c'est plus un problème général à la programmation objet. Une pratique courante veut qu'un objet est responsable de son état et des informations qu'il contient.
Le minimum dans une application est que le modèle métier soit robuste : les informations doivent donc être validées dans le modèle. Y associer un ensemble de tests unitaires pour s'assurer qu'il n'y a pas de régressions.
Ensuite l'interface (vue/controlleur) doit dans l'idéal n'autoriser la saisie que d'information valides vis-à-vis du modèle. Un mask peut être appliqué par exemple côté client, tu peux également faire des vérifications dans le contrôleur, dans le pire des cas l'information non valide arrivera au modèle qui DOIT te lever une belle exception :)
Dans tous les cas, si tu veux te protéger de tentatives de hack SQL, c'est la classe manipulant la base de données qui s'occupe de faire la validation : elle est la seule censée connaître la couche d'accès aux données (ici une base de donnée), elle est donc la seule à savoir quels problèmes potentiels peuvent survenir.