Je me rends compte qu'en posant cette question, j'aurais pu commencer l'apocalypse, mais un de mes collègues utilise beaucoup de codage en ligne dans leurs pages aspx, où comme je préfère utiliser le code-behind.ASP.NET - Inline vs Code-Behind
Y a-t-il un bon et un mauvais moyen ici?
À moins que votre norme de codage ne le confirme.
IMO code-behind aide à la séparation des préoccupations, donc je préfère cela, mais parfois il suffit de traiter avec un fichier est aussi bien.
Le code-behind est l'endroit le plus traditionnel et logique. Si ça marche, ça marche, mais je ne peux pas le supporter dans l'aspx.
Je sais ce que tu veux dire, en ligne pour moi cris ASP classique. Le seul problème avec l'utilisation du code-behind est que je ne peux pas hériter d'une autre page. Au moins, je ne le pense pas. Considérant qu'avec l'argument de mes collègues, ils peuvent hériter d'une page et utiliser le code en ligne qui résout ce problème. Ce débat a été initié par ce problème. – LiamGu
Je pense que asp.net MVC revient à l'inline, dans une certaine mesure. L'histoire se répète. – shahkalpesh
J'ai fait le poste exact un certain temps:
OnDataBinding vs Inline: pros, cons and overhead
Je préfère le code derrière. J'ai généralement une zone #region pour tous les trucs de liaison de données. Il permet aux personnes qualifiées en HTML/CSS de modifier le code HTML et tout ce qu'ils doivent savoir est ce que les contrôles de base à utiliser et à définir l'événement OnDataBinding dans la définition du contrôle. Ils peuvent faire bouger les choses et faire quoi que ce soit et n'ont aucune connaissance de ce qu'il faut réellement pour obtenir les données dans cette base de données car il peut ne pas être aussi simple qu'un simple 'Eval ("quelque chose").
Il n'y a pas de vrai/faux avec ce soit.
Vous pouvez écrire du code en ligne & certains d'entre eux doivent être écrits en code-behind. Cela ne peut pas être absolu. Cela dépend de la lisibilité/maintenabilité de l'écriture de l'autre côté.
EDIT: Comme il est dit, écrire le code pour & humain pour le compilateur.
J'ai tendance à utiliser le code-behind puisque c'est le seul moyen pour WPF et j'essaie de rester cohérent et c'est plus naturel. Mais c'est subjectif.
Eh bien, il y a du code en ligne, et puis il y a du code en ligne. Si vous avez un bloc de script en haut pour vous, page_load, c'est très bien. Mais si vous mélangez beaucoup de piqûres d'abeilles (<% %>) avec le balisage, vous finirez par avoir des problèmes quand ces piqûres d'abeilles ne fonctionnent pas comme vous le feriez avec d'autres commandes du serveur.
Personnellement, je préfère les erreurs de compilation aux erreurs d'exécution, donc j'ai mis toute ma logique dans le code derrière.
Parfois, quand j'ai juste besoin d'une valeur pour apparaître sur la page, je vais mettre <% = SomeValue%> mais même alors, je préfère de beaucoup créer une étiquette et le définir.
Je veux vous assurer que je comprends la question - par en ligne, voulez-vous dire des extraits comme
<a><% some.asp.net.code %></a>
ou voulez-vous dire un contre deux fichiers pour chaque page:
page.aspx
page.aspx.cs
?
Parce que je ne suis pas fan de ce que j'appelle le code « intégré » dans le premier exemple, mais je préfère le code et le balisage dans le même fichier avec un script < runat = « server »>
Le code en ligne pour moi est à la fois
Dupe http : //stackoverflow.com/questions/702343/ondatabinding-vs-inline-pros-cons-and-overhead –
Oui, Kelsey l'a souligné. Bien que pas tout à fait pareil, je cherche s'il y a une manière correcte de faire les choses, surtout pour un projet sur lequel nous allons commencer à travailler. – LiamGu