2010-03-23 5 views
13

Je voudrais demander aux utilisateurs expérimentés, si vous préférez utiliser des contrôles de données sensibles pour ajouter, insérer, supprimer et éditer des données dans la base de données ou vous préférez le faire manuellement.Comment utiliser les contrôles de données sensibles "correctement"?

J'ai développé quelques applications de DB, dans lesquelles pour la "politique facile à utiliser" je cours dans le Web compliqué d'événements de table (afterinsert, afteredit, after ... et beforeedit, beforeinsert, avant ...). Après cela, c'était un travail assez désagréable pour déboguer l'application. Conscient de ce risque (plus tard par une autre application) j'ai essayé d'éviter ce problème, donc j'ai prêté une attention accrue à écrire du code bien, lisible et compréhensible. Tout semblait aller de l'avant depuis le début, mais comme je devais gérer certains éléments de prétraitement avant d'envoyer et de charger des données, je rencontre de nouveau les mêmes problèmes, "lentement et inévitablement". Parfois, je ne pouvais pas utiliser les contrôles dataaware de toute façon, et ce qui semblait être une fonctionnalité «cool» de DAControl au début, il s'est transformé en un obstacle à la fin. J'ai "dû" écrire une routine spéciale pour les contrôles non-dataaware, afin de se comporter en tant que dataaware. Puis je me suis demandé, pourquoi devrais-je utiliser des contrôles de données? Est-il préférable de trouver l'architecture de l'application sur les contrôles non-dataaware? Il faut plus de temps pour écrire du code résistant aux bogues, bien sûr, mais cela en vaut-il la peine? Je ne sais pas ...

Je me est arrivé à plusieurs reprises, comme ensorcelé: le paradis sur l'enfer début à la fin ...

Je ne sais pas, si j'utilise mauvaise méthode pour écrire le programme DB , s'il y a une pratique commune standard comment procéder. Ou si c'est un problème commun à tout le monde?

Merci pour les conseils et vos expériences

Répondre

0

Le secret doit être dans l'automatisation des paramètres DataSet, vous pouvez créer un contrôle qui colle des ensembles de données ainsi que de façon maître-esclave, juste en définissant des liens entre eux. Bien entendu, un tel contrôle devrait être alimenté avec des paramètres de forme d'une autre manière généralisée. Dans ce cas, le formulaire d'appel avec l'identificateur d'entité, tous les jeux de données seront remplis dans un ordre approprié et permettra de mettre à jour les données dans la base de données automatiquement par le fournisseur.

Généralement, il est préférable que les DataSets soient une représentation exacte des tables avec des champs calculés facultatifs (fkInternalCalc fonctionne parfois mieux lorsqu'il est mis à jour avec changement de ligne et non changement de champ). Les contrôles prenant en compte les données constituent l'approche la plus optimale et moins sujet aux erreurs. Comme dans tous les aspects, il y a des exceptions à cela.

Si vous devez écrire trop de fonctions de collage, le problème se situe probablement dans le motif de conception et non dans la VCL.

4

J'ai écrit des applications qui utilisaient des composants sensibles aux données pour les composants de style TTable et les applications qui utilisaient des composants non sensibles aux données.

Ma préférence de nos jours est d'utiliser des composants sensibles aux données mais avec TClientDataSets plutôt que des composants de style TTable.

En utilisant un TClientDataSet je n'ai pas besoin de rendre ma structure d'interface utilisateur imiter ma structure de base de données. Il est assez flexible pour le remplir avec les données de plusieurs tables, puis, lorsque vous appliquez les mises à jour à la base de données, vous pouvez ajouter/supprimer/mettre à jour manuellement les enregistrements comme bon vous semble.

+0

Wayne Niddery a écrit à ce sujet dans son article "Le bon design orienté objet peut-il inclure des contrôles de données?" Vous pouvez le trouver sur http://www.logicfundamentals.com dans la section Articles. – Erwin

0

La plupart du temps, j'utilise des contrôles sensibles aux données liés à une table en mémoire (kbmMemTable) remplie à partir d'une requête.

Les avantages que je vois sont:

  1. J'ai un contrôle total sur toutes les insertions/mises à jour/messages/modifications à la base de données.
  2. Je n'ai pas besoin de m'inquiéter lorsqu'un utilisateur laisse un enregistrement en mode de mise à jour (potentiellement verrouiller d'autres utilisateurs)
  3. Ai-je mentionné un contrôle total sur tous les insertions/mises à jour/publications/modifications?

Utilisation de la est aussi facile tableau en mémoire:

dataset.sql.add('select a.field,b.field from a,b'); 
dataset.open; 
inMemoryTable.loadfromdataset(dataset); 
inMemoryTable.checkpoint; 

Et puis « résoudre » retour à la base de données, vous donne accès aux données originales et nouvelles pour chaque champ dans chaque enregistrement (similaire à un déclencheur) - vous pouvez facilement effectuer une transaction et résoudre une édition entière en millisecondes, même s'il a fallu 30 minutes à l'utilisateur final pour remplir les contrôles sensibles aux données.

0

Avez-vous considéré un O/R mapper pour Delphi comme tiOPF ou hcOPF?

Cela va séparer la logique du domaine métier de la couche base de données. Pour les systèmes de grande taille et anciens, il est même courant d'ajouter une autre couche, la 'Anti Corruption Layer', qui protège le modèle contre les changements dans la conception de la base de données.

Questions connexes