Meilleure pratique du modèle MVC - Comment gérer les données non entrées par l'utilisateur

Question

Donc, ma question est que j'ai un modèle. Mon modèle a des données qui sont renseignées en fonction de l'identifiant transmis via l'URL et défini dans un cookie, et le reste est une entrée utilisateur, qui est validée à l'aide d'annotations de données.

Le "problème" que j'ai rencontré est de savoir comment gérer ces données d'entrée non utilisateur. Dois-je le mettre dans des contrôles cachés et gonfler ainsi (quoique seulement légèrement) ma taille de page, ou est-ce que je "reconstruis" cette partie du modèle sur chaque publication, qui ajoute un autre voyage à la base de données et retour. Je comprends que c'est subjectif, mais je suis curieux de savoir quelle est la pratique standard. Mettre les données dans un champ caché est le moyen le plus simple, mais il ne semble pas correct d'avoir supprimé ViewState pour le ramener, même si c'est en petits morceaux. Plus qui expose vos données à l'utilisateur - pas qu'ils ne pouvaient pas modifier l'URL. Et personne n'aime les voyages inutiles à la base de données.

Oh, et je ne peux pas utiliser la session. Cette application fonctionne dans un environnement à charge équilibrée.

Answer 1

Laissez simplement l'ID dans l'URL. Une url est censée identifier une ressource de toute façon, donc sortir le paramètre de l'url et le stocker de toute autre manière fait juste du travail supplémentaire et fait que votre URL n'identifie pas la ressource à laquelle vous accédez.

Si vous avez d'autres données à envoyer, il est très courant d'envoyer un identifiant dans un champ masqué, en le validant comme n'importe quel autre champ. Si vous pouvez déduire le côté serveur d'informations, cela revient à peser les coûts de reconstruction de ces données par rapport à une demande plus importante. Vous devez mesurer ce qui est le mieux pour votre application pendant le test, mais les deux sont courants dans la pratique. Ne pas oublier les problèmes de sécurité lorsque vous prenez votre décision, cependant, ce n'est pas toute la performance.

En outre, si les données proviennent du client, peu importe à quel point vous pensez que vous le cachez, il s'agit toujours d'une entrée utilisateur. Cela signifie que même si vous ne leur donnez pas de contrôle pour éditer la valeur à l'écran, un utilisateur à moitié averti saura comment la changer.

Answer 2

Je ne pense pas que viewstate soit la solution, car il expose les données internes au navigateur et augmente également votre trafic inutilement.

Si je devais résoudre ce problème, j'utiliserais la session pour stocker de telles données liées à la session. S'il s'agit d'un environnement à charge équilibrée, vous aurez besoin d'une gestion de session distribuée. Le moyen le plus simple de le résoudre consiste simplement à démarrer un service d'état ASP.NET et à commencer à l'utiliser pour gérer les sessions.

Si vous n'aimez pas Microsoft Tech, vous pouvez également utiliser MemCached pour stocker des données de session sur des serveurs memcached. Il y a des fournisseurs pour cela, par exemple this, malheureusement il ne semble plus en développement.

Answer 3

il va être mieux si vous obtiendrez de votre DAL sur chacun,
ce n'est pas bon de mettre des choses inutiles dans votre code html

Imaginons que vous obtenez un utilisateur et mettre son mot de passe dans une entrée cachée , juste parce que tu ne veux pas l'avoir à chaque fois.

ou vous mettez quelque chose dans les entrées cachées et en utilisant firebug quelqu'un change les valeurs de ces entrées.