2008-08-30 5 views
1

Combien un DataSet doit-il représenter? Utilisation de l'exemple d'un système de commande: Lors de l'affichage de votre commande, je montre également une liste d'articles similaires à l'un des vôtres ainsi qu'une liste de nos articles les plus populaires. Bien que vos articles soient emmêlés dans un réseau de relations impliquant vous et vos commandes antérieures, vos fournisseurs préférés et les divers autres types d'informations qui vous concernent en tant que client, les autres articles n'ont pas ces mêmes relations. L'ensemble des requêtes que j'utilise pour naviguer dans l'ensemble des éléments qui vous représentent est différent des requêtes que j'utilise pour l'une de ces autres listes d'éléments. Mon inclination est de créer différents DataSets pour différents types de relations, mais ensuite je crée dix DataTables distincts et cela semble faux. Quand j'instancie le DataSet plus grand même si je ne suis intéressé que par un petit sous-ensemble qui me semble incorrect, et quand j'essaye d'emballer tout cela dans un DataSet, j'ai une grosse chose en désordre avec plusieurs tables d'items l'une à côté de l'autre assez sûr que c'est mal. Peut-être que je suis en train de surévaluer la fonctionnalité de relation de DataSets ou peut-être que j'ai juste besoin de m'en sortir, de toute façon je pourrais utiliser quelques conseils.Combien devrait représenter un DataSet?

Répondre

1

C'est pourquoi je n'utilise pas de jeux de données. Si vous utilisez des ensembles de données fortement typés, vous bénéficiez d'un typage fort, mais vous payez en termes de temps nécessaire pour en créer un même si vous n'en utilisez qu'une partie et son extensibilité en termes de base de code. Si vous voulez modifier un existant et que vous modifiez une définition de ligne, cela créera des ruptures de "shotgun" dans la base de code car chaque définition pour ajouter une nouvelle ligne devra être modifiée car elle ne sera plus compilée.

Pour éviter le scénario ci-dessus, l'approche la plus sensée est d'abandonner généralement une réutilisation raisonnable. Définir un jeu de données par objectif et par utilisation. Cependant, le problème principal est l'utilisation de l'API, vous vous retrouvez avec un jeu de données similaire à un autre jeu de données mais comme il s'agit d'un type de jeu de données différent, vous devez le transformer pour utiliser l'API commune qui est à la fois douloureuse et inélégante. Ceci, ajouté au fait que les jeux de données fortement typés rendent votre code horrible (la longueur des déclarations de type) sont à peu près les raisons pour lesquelles j'ai abandonné les jeux de données et les ai remplacés par des objets métier.

4

Le DataSet est largement surutilisé et surutilisé. Utilisez des collections fortement typées (merci, génériques et propriétés automatiques!). Comme cerise sur le gâteau, vous pouvez maintenant faire des choses de requête cool avec vos objets personnalisés avec LINQ.

Bonne Esposito article sur des ensembles de données par rapport à des objets personnalisés:

http://msdn.microsoft.com/en-us/magazine/cc163751.aspx

propriétés automatiques:

http://weblogs.asp.net/dwahlin/archive/2007/12/04/c-3-0-features-automatic-properties.aspx

LINQ avec vos objets:

http://blogs.msdn.com/wriju/archive/2006/09/16/linq-custom-object-query.aspx