Mi rendo conto che ponendo questa domanda, avrei potuto iniziare l'apocalisse, ma un mio collega utilizza un sacco di codice in linea nelle loro pagine aspx, dove preferisco usare il code-behind.ASP.NET - Inline vs. Code-Behind
C'è un modo giusto e sbagliato qui?
A meno che lo standard di codifica non indichi diversamente.
Il code-code IMO aiuta a separare le preoccupazioni, quindi preferisco, ma a volte anche trattare solo con un file è bello.
Code-behind è il posto più tradizionale e logico. Se funziona, funziona, ma non sopporto di farlo nell'asx.
So cosa intendi, inline a me grida ASP classico. L'unico problema nell'usare il code-behind che ho è che non posso ereditare anche un'altra pagina. Almeno io non la penso così. Considerando che con l'argomento dei miei colleghi, possono ereditare una pagina e utilizzare il codice inline che risolve questo problema. Questo dibattito è stato infatti avviato da questo stesso problema. – LiamGu
Penso che asp.net MVC ritorni ad inlining, in una certa misura. La storia si ripete. – shahkalpesh
ho fatto il post esatto un po 'indietro:
OnDataBinding vs Inline: pros, cons and overhead
preferisco il codice dietro. Di solito ho un'area di #region per tutte le cose legate ai dati. Permette alle persone esperte in HTML/CSS di modificare l'HTML e tutto ciò che devono sapere è quali controlli di base utilizzare e definire l'evento OnDataBinding nella definizione del controllo. Possono spostare le cose e fare qualsiasi cosa e non hanno alcuna conoscenza di ciò che effettivamente serve per ottenere i dati in quel database, in quanto potrebbe non essere semplice come un semplice Eval ("qualcosa") ;.
Non c'è giusto/sbagliato in entrambi.
È possibile scrivere del codice in linea & parte di esso deve essere scritto nel code-behind. Non può essere assoluto. Dipende da quanto leggibile/gestibile diventa quando lo scrivi dall'altra parte.
MODIFICA: Come si dice, scrivere codice per il numero & umano per il compilatore.
Tendo ad usare il code-behind poiché è l'unico modo per WPF e cerco di rimanere coerente e mi sembra più naturale. Ma questo è soggettivo.
Bene, c'è il codice inline e poi c'è il codice inline. Se hai un blocco di script in cima per te page_load, va bene. Ma se stai mescolando un sacco di punture di api (<% %>) con il markup, alla fine inizierai ad avere problemi quando quelle punture di api non funzionano come vorresti con altri controlli del server.
Personalmente preferisco gli errori di compilazione agli errori di run-time, quindi ho messo tutta la mia logica nel codice dietro.
Occasionalmente quando ho solo bisogno di un valore da mostrare nella pagina, inserisco <% = SomeValue%> ma anche in questo caso preferisco di gran lunga creare un'etichetta e impostarla.
Voglio fare sicuro di aver capito la domanda - da in-line, vuoi dire frammenti come
<a><% some.asp.net.code %></a>
O vuoi dire uno contro due file per ogni pagina:
page.aspx
page.aspx.cs
?
perché io non sono un fan di quello che io chiamo il codice 'incorporato' nel primo esempio, ma io preferisco il codice e markup nello stesso file con un < sceneggiatura runat = "server">
Il codice inline per me è sia
Dupe di http : //stackoverflow.com/questions/702343/ondatabinding-vs-inline-pros-cons-and-overhead –
Sì, Kelsey l'ha fatto notare. Anche se non proprio la stessa cosa, sto cercando se c'è un modo corretto di fare le cose, soprattutto per un progetto sul quale stiamo per iniziare a lavorare. – LiamGu