Le projet actuel utilise le modèle de développement d'ensembles de données et la structure à trois niveaux.
En fait, qu'il s'agisse ou non d'un contrôle de source de données à trois niveaux, le plus grand avantage de l'utilisation du contrôle de source de données est le suivant : dans le passé, des requêtes liées à plusieurs tables étaient nécessaires, mais nombre d'entre elles peuvent désormais être éliminées. vous aide automatiquement à le faire ;) N'est-ce pas très relaxant et agréable ?
Par exemple, la table A comporte trois clés étrangères, ID1, ID2, ID3. Il vous suffit de convertir les trois champs en modèles, puis de sélectionner les contrôles appropriés à lier aux trois contrôles de source de données. OK, vous n'avez pas à vous soucier du reste.
Deuxièmement, objdatasource parmi les contrôles de source de données est en effet facile à utiliser. D'autres contrôles de source de données sont soit trop simples, soit trop spécialisés (plan du site). Ce n'est qu'avec la coopération de la structure à trois niveaux que la puissance du contrôle de source de données peut être pleinement exercée. Ce que je peux écrire à la main, je n'ai encore rien rencontré que les objD ne puissent pas faire. Mais vous devez « changer votre cerveau » et changer votre façon de penser. L’implémentation n’est en effet pas la même chose que l’écriture de code à la main. J'ai maintenant une page de code. Dans le passé, l'arrière-plan du projet d'autres personnes utilisait plus de 1 000 lignes, mais maintenant je n'utilise que moins de 400 lignes. On ne peut que dire que les objD présentent encore des avantages à certains égards.
De plus, lors de la création d'un adaptateur, vous devez faire attention à savoir si le type de données généré est cohérent avec la base de données. En particulier, le type char(1) est généralement défini sur byte. Si le code est correct mais qu'une erreur se produit, cela. est souvent le problème. Modifiez-le simplement et tout ira bien
http://www.cnblogs.com/emilchan/archive/2006/11/30/578033.html