JQuery Datatables e ASP.NET MVC – Duas abordagens

Olá a todos,

Após quase 2 anos desenvolvendo em PHP, retorno ao continente Microsoft, no país .NET, numa cidadezinha com o nome de ASP.NET, na rua C#.

De agora em diante, espero fazer publicações relacionadas a essa tecnologia. Não guardo rancor contra o PHP, o problema sou eu, não ele, me entende? Quero o melhor para o PHP, por isso preciso me afastar (papo aleatório para dar um FORA).

Pra começar a brincadeira, que falar sobre Datatables e ASP.NET MVC! Separei duas abordagens para vocês, ilustres visitantes.

Código fonte para acompanhar o artigo.

Abordagem 1: NO_CONFIG

A abordagem 1 é basicamente o que o título diz. Nada de configuração. Você só vai trazer os dados do servidor e cuspir tudo na tela. Em seguida, aplica o plugin datatables e TCHA-DÃ, você tem uma tabela com ordenação, paginação e busca.

Desenvolvedores experientes já estão com as pedras na mão para lançar. Como assim, vamos trazer TODO o conteúdo de uma só vez na tela?! E a performance? E a carga de dados? E a […]?

HEY, LISTEN! Esta é uma abordagem. Podemos prototipar dessa maneira. Podemos usar ela em etapas iniciais do projeto e otimizar com o tempo.

Lidando com telas simples, com poucos dados a serem exibidos ( aprox. 150 registros), é realmente necessário otimizar? Vale a pena? Não estamos colocando performance na frente de funcionamento?

É uma questão delicada que deve ser averiguada. Minha opinião: Verifique se você pode usar. Teste no ambiente do cliente. Deixe que o cliente use o software desta maneira (após a carga de dados iniciais).

Caso o uso esteja adequado, adiante o seu projeto. Siga em frente. Otimize quando for necessário. Essa pode ser uma abordagem útil para se ganhar tempo em relação a outras áreas críticas do software (como as funcionalidades de vendas, relatórios de movimentos, etc).

USE COM PARCIMONIA. Analise. Teste. Se não der, otimize.

Abordagem 2: Carga controlada

A segunda abordagem assume que o usuário fará uma filtragem inicial dos dados, somente após o filtro é que o datatables exibirá os dados e seu filtro, ordenação e paginação somente atingiram os dados que vieram do servidor.

Já estamos melhorando na questão de performance: Não trazemos mais TODOS OS DADOS, “apenas” a parcela que o usuário requisitou. O Datatables vai agir sobre essa parcela.

Claro que o cliente sempre pode fazer uma requisição absurda: Imagine que estamos lidando com data inicial e final de busca numa tela de movimentações. Se o cliente buscar por 3 anos de movimentações, esta abordagem será tão inútil quanto a primeira.

Mas vamos assumir que estamos numa tela mais simples ou que criamos os mecanismos de prevenção: não permitir mais que 6 meses de busca, obrigar a informar o tipo de movimentação, etc.

Esta abordagem se torna válida, sendo muito fácil de configurar e utilizar. Ganhamos tempo em desenvolvimento. Siga em frente e caso seja necessário, otimize! Mude a abordagem, não tenha medo de atualizar seu código.

Fechando a conta

Essas duas abordagens ilustradas são as mais simples que eu conheço. Podem ser utilizadas em cenários de pouca carga de forma fácil, ganhando tempo no desenvolvimento do software. Lembre-se, nestes exemplos estamos apenas tratando as listagens (READ) dos dados. Um software completo precisa de vários CRUDs (Create, Read, Update, Delete). Cada uma das etapas pode ser extremamente complexa e você pode estar quebrando a cabeça com uma listagem de produtos que nunca terá mais de 20 itens.

Existem outras abordagens, especialmente a abordagem do processamento server side: Apenas será exibido na tela a página e os dados relativos a ela.

Mudou a pesquisa? Nova carga vinda do servidor, seguindo a paginação, filtro e ordem escolhidos pelo usuário. Esta abordagem é a melhor do ponto de vista de performance, pois estamos sempre buscando e exibindo exatamente o que o usuário quer ver (nunca menos nem mais).

Porém, como foi dita na abordagem NO_CONFIG, se lembre de analisar. Você realmente precisa dessa complexidade? A conexão do seu cliente não se sai melhor trazendo uma carga de dados inicial ao invés de fazer uma carga a cada página?

Em todos os momentos, devemos verificar o custo x benefício da abordagem e as suas particulariedades.

Dicas? Sugestões? Mande nos comentários!

Abraços e até mais!

Anúncios

Um pensamento sobre “JQuery Datatables e ASP.NET MVC – Duas abordagens

  1. Pingback: DataTables Totalmente no Server Side | Diego Doná | Designer, Developer

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

w

Conectando a %s