Meilleures pratiques pour passer des données d'asp.net-mvc à javascript

Question

J'ai beaucoup travaillé avec ASP.NET MVC et Javascript/jQuery ces derniers temps et je semble me diriger dans une direction où je dois toujours passer une valeur dynamique "à" mon javascript. Lorsque le script est juste dans la page, je l'ai fait quelque chose comme ceci:

var isEditable = <%=ViewData["editable"]%> 

J'aime comment cela est facile et rapide & comme j'injecter une valeur en HTML. Mais ça sent. Vraiment, vraiment mauvais. Et cela rompt l'intellisense et le formatage de code de Visual Studio, rendant mes scripts difficiles à lire et à comprendre.

Il m'a eu une autre solution serait de transmettre mes données à un champ caché, et avoir la référence Javascript que ...

<input type="hidden" id="editable" value="<%=ViewData["editable"]%>" /> 
var isEditable = $("#editable").attr("value"); 

Ceci est probablement beaucoup mieux car il conserve intact le script et me permettrait de le déplacer vers un fichier .js externe. Mais quelque chose à propos de cette solution ne semble pas idéal non plus. Ou est-ce juste moi?

Quelqu'un peut-il recommander des solutions & les meilleures pratiques pour transmettre des données dans vos scripts? Suis-je sur la mauvaise voie si mes scripts finissent par s'appuyer fortement sur les viewdata de mes contrôleurs?

Answer 1

Je passe parfois des données à mes pages en écrivant un objet de configuration à la page via un sérialiseur JSON:

var pageConfig = <%= ServerConfig.ToJson() %>; 

Si vous devez écrire la méthode toJSON vous. Cela maintient l'état de la page bien contenu, de sorte qu'il n'y a qu'un seul endroit où vous injecter des valeurs de serveur. Tout à partir de maintenant est purement javascript. Dans votre exemple, vous pouvez alors faire:

var isEditable = pageConfig.isEditable; 

même dans un fichier js externe, si pageConfig est mondiale. Dans ce cas, cependant, vous devriez correctement l'espace de noms: MY_APP.pageConfig peut-être.

Answer 2

Vous allez injecter cette information d'une manière ou d'une autre. Et OMI, votre premier exemple ne sont pas vraiment différents du second.

Une autre solution consiste à avoir une classe JS (ou prototype?) Qui acceptera un objet options. Bien que ce soit vrai, ce n'est pas vraiment différent des exemples que vous avez donnés. Mais encore, peut-être que vous voudriez aller de cette façon.

$(function() { 
    myClass.init({ isEditable: <%=ViewData["editable"]%>, 
     another: '<%=ViewData["another"]%>' }); 
}); 

Answer 3

Je pense que @ çağdaş fait un bon point, mais n'oubliez pas de vérifier le côté serveur aussi. Si vous définissez un champ sur "lecture seule", rien n'empêche l'utilisateur de modifier cet indicateur, de modifier un champ en lecture seule et de le soumettre.

Answer 4

Toute l'activité de Ajax est charger informations de manière asynchrone. Si vous faites le travail d'Ajax (charger l'info et la garder dans une variable), cela en enlève le pouvoir. Pourquoi ne pas essayer JQuery et utiliser son Ajax, ou Obtenir des fonctions pour charger le contenu dynamiquement. Cela aiderait votre page à se charger plus rapidement.