Asp.Net GridView: Bon ou mauvais/Quels types de données utiliser pour la liaison?

Question

Donc, cette question peut être un peu vague, mais j'ai des discussions constantes à ce sujet:

Lors de la conception d'une page Asp.Net, beaucoup de fois vous pourriez juste vouloir jeter un GridView rapide et sale sur la page . Lorsque vous parcourez cette route, vous disposez des différentes options de source de données (j'utilise généralement ObjectDataSource lié à un objet métier) et vous pouvez également lier manuellement.

J'ai vu beaucoup de variations sur ce que les types de données peuvent fournir automatiquement la fonctionnalité de tri dans la grille. J'ai vu des personnes traduire littéralement leurs collections POCO personnalisées dans DataTables dans leurs objets métier afin que GridViews puisse plus facilement prendre en charge ce type de comportement.

Vous pouvez vraiment obtenir beaucoup de comportements différents d'un GridView en gérant vous-même tous les événements disponibles (OnSorting, OnUpdating, etc.) et cela peut finir par être hautement personnalisé à long terme. Même si c'est le cas, vous pouvez rencontrer d'autres petits problèmes sournois comme ne pas avoir la possibilité d'utiliser la touche "Entrée" effectuer automatiquement l'opération de mise à jour pour une ligne donnée. En effet, le bouton par défaut sur la page peut être en dehors de GridView, et ASP.Net vous permet uniquement de spécifier le bouton par défaut pour un panneau donné et n'honore pas ce comportement pour les boutons dans les modèles GridView. C'est juste un exemple, remarquez. Il y a aussi bien sûr la question de savoir si la page doit revenir à la source de données à chaque opération de filtrage ou si la source de données entière doit être mise en cache dans ViewState sur la page pour permettre le filtrage/tri sans déplacement vers la base de données Voici donc la question ultime: est-il raisonnable d'utiliser un GridView sur une page où vous voulez des opérations CRUD de base, même si cela peut impliquer de transformer vos collections personnalisées en un type de DataTable? GridViews devrait-il être complètement abandonné au profit de quelque chose d'autre comme DataList, ListView ou Repeater? Ces dernières options peuvent certainement être plus flexibles, mais cela signifie-t-il que la gestion par défaut de la sélection de lignes, de l'édition, du tri, etc. de GridView doit être reconstruite pour chaque scénario?

Toutes les pensées raisonnables sur ce sujet apprécié!

Answer 1

Je viens de réaliser cette question était encore traîner ici alors voici ma conclusion sur ce sujet:

Je pense toujours qu'il est utile d'intégrer un contrôle standard GridView dans une page ASP.Net. Je pense toujours qu'il est déraisonnable de traiter chaque événement de tri dans le code-behind d'une page car cela crée un véritable cauchemar de maintenance et claque votre code d'interaction et de logique métier trop près de la "Vue" en termes MVC. Ce que je ne savais pas, c'est à quel point GridViews peut être étroitement intégré avec les différentes commandes DataSource. Je savais que si GridView était connecté à un SqlDataSource, il exécuterait diverses opérations CRUD directement sur la base de données tout en appliquant ses propres techniques de tri et de pagination, mais cela ne se traduirait pas bien par l'utilisation d'un ObjectDataSource avec un objet métier. J'ai pensé.

Il s'avère qu'il existe trois propriétés cruciales sur le contrôle ObjectDataSource qui lui permet de fournir dynamiquement une méthode sur un objet métier avec des paramètres de tri et de pagination.

Ces propriétés sont: SelectCountMethod, SortParameterName, StartRowIndexParameterName et MaximumRowsParameterName.Ces propriétés associées à l'indicateur EnablePaging requis modifient la signature attendue de votre méthode "Select" et démarrent automatiquement à l'aide de votre méthode SelectCount pour obtenir le nombre total d'enregistrements renvoyés, en utilisant la taille de page et l'état actuel de votre GridView votre ensemble de résultats et le nombre d'éléments à sélectionner au-delà de ce point de départ, et commence à soumettre une expression de tri de style SQL avec tous les appels à votre méthode Select. Dans l'ensemble, c'était un grand pas en avant, mais si vous utilisez des collections personnalisées de classes POCO, ou si vous exécutez des requêtes sur un contexte d'objet LinqToSql ou EF, vous devez toujours traduire les paramètres StartRowIndex et MaximumRow sous une forme quelconque d'une combinaison Skip(). Take() (qui est assez simple et évidente) et traduit l'expression Sort en un certain type de requête par rapport à votre contexte d'objet ou collection en mémoire. Je n'entrerai pas dans tous les détails détaillés ici, mais fondamentalement, la solution consiste à utiliser les capacités et la réflexion de Dynamic-Linq pour définir une expression de requête contre votre collection en mémoire avec seulement la chaîne de tri pour continuer.

La chaîne de tri contiendra un nom de champ et une direction de tri (uniquement si elle est descendante) dans le format "FieldName DESC" typique. En analysant cette chaîne, vous pouvez utiliser une réflexion sur votre type spécifique pour créer une expression en utilisant le nom de la propriété correspondante dans la chaîne Sort. Le principal avantage ici est qu'avec seulement quelques ajustements à la méthode select et l'utilisation d'une extension Linq personnalisée pour gérer la conversion d'une chaîne de tri en une expression lambda, vous pouvez aller à votre travail habituel de câblage GridViews à logique métier avec génération de tri et fonctionnalité de pagination. Comme il a été mentionné dans la question initiale, je noterai que cette solution aboutira à un accès à la base de données sur pratiquement chaque chargement de page, mais finalement la quantité de données renvoyée devrait être beaucoup plus petite et plus ciblée.

Answer 2

Ayant juste eu à utiliser à nouveau gridviews pour la première fois depuis des années, je me rappelle pourquoi je ne les ai pas utilisés depuis si longtemps. Les GridView sont parfaits pour ce qu'ils sont conçus à un niveau de base, mais malheureusement, la plupart du temps, l'utilisateur final voudra plus de fonctionnalités et c'est là où ils commencent à manquer. Bien que vous puissiez personnaliser et étendre les vues de la grille un peu, comme vous l'avez noté, cela ouvre une boîte de Pandore complètement différente. Donc, pour moi, j'essaie de m'en tenir aux vues en grille comme outil de génération de rapports. Au-delà de tout ça, il me semble que je passe beaucoup de temps à le personnaliser et à le peaufiner pour obtenir quelque chose de proche de ce dont j'ai besoin, mais cela n'en vaut pas la peine.