Si dovrebbe associare dati con Eval su aspx o eseguire l'override di ItemDataBound nel code-behind?

5

Per i controlli associati ai dati (Repeater, ListView, GridView, ecc.), qual è il modo preferito per legare i dati?

L'ho visto dove le persone usano Eval () direttamente su aspx / ascx all'interno del controllo associato ai dati per estrarre il campo dati, ma a me sembra solo così ... inelegante. Sembra particolarmente inelegante quando i dati devono essere manipolati in modo da finire con i metodi di shim come <%# FormatMyData(DataBinder.Eval(Container.DataItem, "DataField")) %> nel tuo controllo.

Personalmente, preferisco inserire controlli letterali (o altri controlli appropriati) e collegarli all'evento OnItemDataBound per il controllo e popolare tutti i dati nei loro campi appropriati nel code-behind.

Ci sono dei vantaggi nel farne uno rispetto all'altro? Preferisco quest'ultimo, perché per me ha senso dividere in compartimenti la logica di associazione dei dati e il livello di presentazione. Ma forse sono solo io.

    
posta George Chang 25.01.2012 - 05:49
fonte

3 risposte

4

Ti suggerisco di passare attraverso questa domanda SO: Eval e ItemDataBound o RowDataBound per visualizzare i dati, quale è meglio?

Base sulla comparsione dello spettacolo sul titolo: Best practice ASP.NET di Real World Utilizzo Il meccanismo di espressione inline format (cioè tag) è migliore del meccanismo di hanlder degli eventi (tramite ItemDataBound).

Come ho spiegato a questo proposito, la sintassi DataBinder.Eval utilizza la riflessione e dovrebbe essere evitata se è possibile determinare il tipo di oggetto in fase di progettazione. Rif: Evitare DataBinder.Eval in ASP.NET

Controlla questo per le prestazioni e la scalabilità di Asp.net:

    
risposta data 25.01.2012 - 06:46
fonte
3

Prima di tutto: Eval è piuttosto male. Come cita la risposta di @ NiranjanKala, utilizza Reflection per ottenere il valore della proprietà / campo rilevanti e l'utilizzo di Reflection per ottenere i valori dai membri degli oggetti è molto lento (vedi questo articolo per maggiori dettagli).

Come per le altre due sintassi, dipende davvero. Ero un sostenitore della sintassi del binding di eventi, in quanto riduce il disordine nel file ASPX e mantiene separata la logica di associazione e il markup. Inoltre, è facile eseguire il debug e puoi utilizzare altre funzionalità come i sub-repeater che condividono modelli con il ripetitore genitore per i dati gerarchici o la possibilità di attivare e disattivare altri controlli all'interno del ripetitore in base ai dati accessibili. Penso che si adatti davvero all'approccio "stateful web" usato da WebForms.

Tuttavia, più recentemente ho fatto un sacco di MVC e puoi davvero applicare un approccio simile ai ripetitori; associare un oggetto preformattato e non è più necessario preoccuparsi che i metodi "shim" siano nell'ASPX:

protected class MyUiBoundClass
{
   public string DataField {get;set;}
}

public IEnumerable<MyUiBoundClass> PrepareForBind(IEnumerable<MyEntity> entities)
{
    return entities.Select(x => 
                new MyUiBoundClass {
                    DataField = FormatMyData(entity.DataField)
                });
}

public void LoadAndBindData()
{
    /// Load some data from somewhere.
    IEnumerable<MyEntity> myData = this.SomeService.LoadMyData();
    IEnumerable<MyUiBoundClass> myFormattedData = PrepareToBind(myData);

    this.MyRepeater.DataSource = myFormattedData;
    this.MyRepeater.DataBind();
}

Se si utilizza questo modello in stile ViewModel, si separa la formattazione dei dati dal markup e si utilizza ancora il più veloce e più conciso <% #% > sintassi. Inoltre, hai praticamente risolto il problema "più difficile da eseguire il debug" che normalmente viene fornito con <% #% > sintassi, come si troverà tutto il codice debug-degno nel metodo PrepareToBind.

    
risposta data 25.01.2012 - 22:42
fonte
1

Penso che la costruzione di codebehind abbia alcuni svantaggi significativi nel flusso di lavoro, principalmente per il fatto che la modifica della formattazione dell'output per un'applicazione Web richiede una ricompilazione.

Personalmente, mentre stavo facendo i webform ASP.NET, avrei lanciato il Container.DataItem sull'oggetto appropriato e poi mi legherei direttamente a quell'oggetto. Inoltre apre la porta a una formattazione più intelligente e, ad esempio, puoi accedere ai membri di detto oggetto.

Per quanto riguarda le prestazioni, non penso che sia probabilmente un lavaggio nelle condizioni del mondo reale. In genere è sufficiente il trasferimento di dati su una rete remota che qualsiasi micro ottimizzazione che si potrebbe fare nel rendering della lista non farà mai la differenza.

    
risposta data 25.01.2012 - 16:18
fonte

Leggi altre domande sui tag