Il codice in linea nelle pagine ASPX è una buona pratica?

Question

Se utilizzo il codice seguente perdo la possibilità di fare clic con il pulsante destro del mouse sulle variabili nel code-behind e di rifattorizzarle (rinominarle in questo caso)

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

Vedo questa pratica ovunque, ma mi sembra strano poiché non riesco più a ricevere errori in fase di compilazione se cambio il nome della proprietà.Il mio approccio preferito è fare qualcosa del genere

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

e poi nel codice sottostante

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

Sono davvero interessato a sapere se le persone pensano che l'approccio di cui sopra sia migliore poiché è quello che vedo sempre sui siti e blog di codifica più popolari (ad es.Scott Guthrie) ed è un codice più piccolo, ma tendo a utilizzare ASP.NET perché è compilato e preferisco sapere se qualcosa è rotto in fase di compilazione, non in fase di esecuzione.

Answer 1

Non la definirei una cattiva pratica (alcuni non sarebbero d'accordo, ma perché ci hanno dato questa opzione in primo luogo?), ma direi che migliorerai la leggibilità e la manutenibilità complessive se non ti sottometti a questa pratica.Hai già espresso un buon punto, ovvero la limitazione delle funzionalità IDE (ad esempio, ispezione in fase di progettazione, avviso in fase di compilazione, ecc.).

Potrei andare avanti all'infinito su quanti principi viola (riutilizzo del codice, separazione degli interessi, ecc.), ma mi vengono in mente molte applicazioni là fuori che infrangono quasi ogni principio, ma funzionano ancora dopo diversi anni.Per quanto mi riguarda, preferisco rendere il mio codice il più modulare e manutenibile possibile.

Answer 2

È noto come spaghetti code e molti programmatori lo trovano discutibile...poi ancora, se tu e gli altri sviluppatori della tua azienda lo trovate leggibile e gestibile, chi sono io per dirvi cosa fare.

Di sicuro, però, usa include per ridurre la ridondanza (DRY - non ripeterti)

Answer 3

Lo uso solo occasionalmente e generalmente per qualche motivo particolare.Sarò sempre uno sviluppatore più felice con il mio codice completamente separato dal mio markup HTML.È in qualche modo una preferenza personale, ma direi che questa è una pratica migliore.

Answer 4

Tocca a voi.A volte il codice "spagehetti" è più facile da mantenere che costruire/utilizzare un sistema completo di template per qualcosa di semplice, ma una volta che si ottengono pagine abbastanza complicate, o più specificamente, una volta che si inizia a includere molta logica nella pagina stessa, può diventare sporca molto velocemente.

Answer 5

Penso che sia interessante che più asp.net richieda codice nelle pagine aspx.Il listview in 3.5 e persino ASP.NET MVC.L'MVC non ha praticamente alcun codice dietro, ma codice nelle pagine per visualizzare le informazioni.

Answer 6

Se lo pensi in termini di sviluppo del modello, allora è saggio tenerlo nella vista e non nel code-behind.Cosa succede se è necessario passare da un'ancora a una voce di elenco con JS discreto per gestire un clic?Sì, questo non è l'esempio migliore, piuttosto proprio quello, ed esempio.

Cerco sempre di pensare in termini di se avessi un designer (HTML, CSS, qualsiasi cosa), cosa gli farei fare e cosa farei nel codice dietro, e come non pestarci i piedi a vicenda.

Answer 7

È solo una cattiva pratica se non riesci a incapsularla bene.

Come ogni altra cosa, puoi creare spaghetti code sgradevoli e illeggibili, tranne che ora hai dei tag di cui accontentarti, che per progettazione non sono le cose più leggibili al mondo.

Cerco di mantenere tonnellate di if fuori dal modello, ma un incapsulamento eccessivo porta a dover cercare in 13 posti diversi per vedere perché div x non si attiva per il client, quindi è un compromesso.

Answer 8

Non lo è, ma a volte è un male necessario.

Prendi il tuo caso come esempio, anche se il codice dietro sembra avere una migliore separazione delle preoccupazioni, ma il problema è che potrebbe non separare le preoccupazioni così chiaramente come desideri.Di solito quando eseguiamo il codice dietro le cose non stiamo costruendo le app nel framework MVC.Anche il codice dietro il codice non è facile da mantenere e testare comunque, almeno se paragonato a MVC.

Se stai creando app ASP.NET MVC, penso che sarai sicuramente bloccato con il codice in linea.Ma costruire nel modello MVC è il modo migliore per procedere in termini di manutenibilità e testabilità.

Sommare:il codice inline non è una buona pratica, ma è un male necessario.

I miei 2 centesimi.

Answer 9

Normalmente lo uso in questo modo.

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