Le code en ligne dans vos pages aspx est-il une bonne pratique?

Question

Si j'utilise le code suivant, je perds la possibilité de cliquer avec le bouton droit de la souris sur les variables du code derrière et de les refactoriser (les renommer dans ce cas)

<a href='<%# "/Admin/Content/EditResource.aspx?ResourceId=" + Eval("Id").ToString() %>'>Edit</a>

Je vois cette pratique partout, mais cela me semble bizarre, car je ne suis plus en mesure d’obtenir des erreurs de compilation si je change le nom de la propriété. Mon approche préférée est de faire quelque chose comme ça

<a runat="server" id="MyLink">Edit</a>

puis dans le code derrière

MyLink.Href= "/Admin/Content/EditResource.aspx?ResourceId=" + myObject.Id;

Je suis vraiment intéressé d'entendre si les gens pensent que l'approche ci-dessus est meilleure car c'est ce que je vois toujours sur les sites de codage et les blogs populaires (par exemple, Scott Guthrie) et que c'est un code plus petit, mais j'ai tendance à utiliser ASP.NET car est compilé et préfère savoir si quelque chose est cassé au moment de la compilation, pas au moment de l’exécution.

Answer 1

Je n'appellerais pas cela une mauvaise pratique (certains seraient en désaccord, mais pourquoi nous ont-ils donné cette option en premier lieu?), mais je dirais que vous améliorerez la lisibilité et la maintenabilité globales si vous ne vous soumettez pas à cette pratique . Vous avez déjà indiqué un bon point, à savoir la limitation des fonctionnalités de l'EDI (inspection de la conception, avertissement de la compilation, etc.).

Je pourrais continuer encore et encore sur le nombre de principes violés (réutilisation de code, séparation des problèmes, etc.), mais je peux penser à de nombreuses applications qui cassent presque tous les principes, mais fonctionnent toujours après plusieurs années. Pour ma part, je préfère rendre mon code aussi modulaire et maintenable que possible.

Answer 2

Il est connu sous le nom de code spaghetti et beaucoup de programmeurs le trouvent désagréable ... si vous et les autres développeurs de votre entreprise le trouviez lisible et maintenable, qui devrais-je vous dire quoi faire?

Bien sûr, utilisez includes pour réduire la redondance (DRY - ne vous répétez pas)

Answer 3

Je ne l'utilise que de temps en temps, et généralement pour une raison particulière. Je serai toujours un développeur plus heureux avec mon code entièrement séparé de mon balisage HTML. C'est une préférence personnelle, mais je dirais que c'est une meilleure pratique.

Answer 4

C'est à vous de voir. Parfois, " spagehetti " Le code est plus facile à gérer que de créer / utiliser un système complet de templates pour quelque chose de simple, mais une fois que vous avez des pages assez compliquées, ou plus précisément, une fois que vous avez commencé à inclure beaucoup de logique dans la page elle-même, elle peut rapidement être modifiée.

Answer 5

Je pense qu'il est intéressant de noter que davantage d'asp.net nécessite du code dans les pages aspx. La listview dans 3.5 et même ASP.NET MVC. Le MVC n'a fondamentalement aucun code derrière, mais un code dans les pages pour rendre les informations.

Answer 6

Si vous envisagez le développement de modèles, il est sage de le conserver dans la vue, et non dans le code. Que faire si, s'il est nécessaire de passer d'une ancre à un élément de liste avec JS discret pour gérer un clic? Oui, ce n’est pas le meilleur exemple, mais juste cela et cet exemple.

J'essaie toujours de penser si j'avais un designer (HTML, CSS, n'importe quoi), qu'est-ce que je le ferais faire et que ferais-je dans le code derrière, et comment ne pas marcher sur les autres orteils.

Answer 7

Ce n'est qu'une mauvaise pratique, si vous ne pouvez pas bien l'encapsuler.

Comme pour tout le reste, vous pouvez créer du code spaghetti vilain et illisible, sauf que vous avez maintenant des balises avec du contenu, qui par leur conception ne sont pas les choses les plus lisibles au monde.

J'essaie de garder des tonnes de données si elles ne sont pas dans le modèle, mais une encapsulation excessive conduit à devoir regarder dans 13 endroits différents pour voir pourquoi div x ne renvoie pas le client, c'est donc un compromis.

Answer 8

Ce n'est pas, mais parfois c'est un mal nécessaire.

Prenez votre cas pour exemple, bien que le code derrière semble mieux séparer les préoccupations, mais le problème est qu’il ne sépare pas les préoccupations aussi clairement que vous le souhaitez. Habituellement, lorsque nous faisons le code derrière des choses, nous ne construisons pas les applications dans le framework MVC. Le code derrière le code n’est pas non plus facile à maintenir et à tester, du moins lorsque comparé à MVC.

Si vous construisez des applications ASP.NET MVC, je pense que vous êtes sûrement coincé avec du code en ligne. Cependant, la construction du modèle MVC est la meilleure façon de procéder en termes de maintenabilité et de testabilité.

En résumé: le code en ligne n’est pas une bonne pratique, mais un mal nécessaire.

Mes 2cents.

Answer 9

Normalement, j'utilise comme ça.

<a href='<%# DataBinder.Eval(Container.DataItem,"Id",""/Admin/Content/EditResource.aspx?ResourceId={0}") %'>