Deve-se ligar dados com o Eval no aspx ou sobrescrever o ItemDataBound no code-behind?

5

Para controles de vinculação de dados (Repetidor, ListView, GridView, etc.), qual é o modo preferido de vincular dados?

Eu vi onde as pessoas usam Eval () diretamente no aspx / ascx dentro do controle de limite de dados para puxar o campo de dados, mas para mim, parece tão ... deselegante. Parece particularmente deselegante quando os dados precisam ser manipulados, então você acaba com métodos de correção como <%# FormatMyData(DataBinder.Eval(Container.DataItem, "DataField")) %> dentro do seu controle.

Pessoalmente, eu prefiro colocar em controles Literal (ou outros controles apropriados) e anexar ao evento OnItemDataBound para o controle e preencher todos os dados em seus campos apropriados no code-behind.

Existe alguma vantagem de fazer um sobre o outro? Eu prefiro o último, porque para mim faz sentido compartimentar a lógica de vinculação de dados e a camada de apresentação. Mas talvez seja só eu.

    
por George Chang 25.01.2012 / 05:49
fonte

3 respostas

4

Sugiro que você passe por essa pergunta do SO: Evento Eval e ItemDataBound ou RowDataBound para exibir dados, qual é o melhor?

Baseie-se na comparação de desempenho no título: Práticas recomendadas do mundo real do ASP.NET O mecanismo de expressão de formato inline (isto é, tag) é melhor que o mecanismo de evento hanlder (via ItemDataBound).

Como eu explorei sobre isso, a sintaxe DataBinder.Eval usa reflexão e deve ser evitada se você puder determinar o tipo de objeto em tempo de design. Ref: Evitando DataBinder.Eval no ASP.NET

Verifique se isso para desempenho e escalabilidade do Asp.net:

    
por 25.01.2012 / 06:46
fonte
3

Primeiro: Eval é muito ruim. Como a resposta de @NiranjanKala menciona que usa Reflection para obter o valor da propriedade relevante / campo, e usando o Reflection para obter valores de membros do objeto é muito lento (veja este artigo para mais detalhes).

Quanto às outras duas sintaxes, isso realmente depende. Eu costumava ser um proponente da sintaxe de vinculação de eventos, pois reduz a desordem no arquivo ASPX e mantém a lógica de vinculação de dados e a marcação separadas. Além disso, é fácil depurar e você pode fazer uso de outros recursos, como sub-repetidores que compartilham modelos com o repetidor pai para dados hierárquicos, ou a capacidade de ativar e desativar outros Controles dentro do repetidor com base em dados acessíveis. Eu acho que realmente se encaixa com a abordagem "stateful web" que o WebForms usa.

No entanto, mais recentemente eu tenho feito muito MVC e você pode realmente aplicar uma abordagem semelhante aos repetidores; ligar um objeto pré-formatado, e você não precisa mais se preocupar com os métodos de "shim" que estão no 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 você usar esse padrão em estilo ViewModel, separará a formatação dos dados da marcação e ainda conseguirá usar os termos mais rápidos e mais concisos <% #% > sintaxe. Além disso, você praticamente resolveu o problema "mais difícil de depurar" que normalmente vem com as tags <% #% > sintaxe, como você encontraria todo o código digno de depuração no método PrepareToBind.

    
por 25.01.2012 / 22:42
fonte
1

Eu acho que construir em codebehind tem algumas desvantagens significativas no fluxo de trabalho - principalmente que alterar a formatação de saída para um aplicativo da Web requer uma recompilação.

Pessoalmente, quando eu estava fazendo webforms do asp.net, eu iria converter o Container.DataItem para o objeto apropriado e, em seguida, vincular diretamente a esse objeto. Também abre a porta para uma formatação mais inteligente e você pode acessar os membros do objeto.

Em termos de desempenho, não acho que seja provavelmente uma lavagem em condições do mundo real. Normalmente, há uma transferência de dados suficiente em uma rede remota que qualquer otimização micro que alguém possa fazer ao renderizar a lista nunca fará diferença.

    
por 25.01.2012 / 16:18
fonte

Tags