Quel est le meilleur modèle de conception OO pour la gestion des objets du registre Windows (ou du système de fichiers)?

Question

Je construis une classe ou deux basée sur StdRegProv pour gérer le registre Windows via la classe COM de PHP. Pour référence à tous les types et méthodes StdRegProv connus, voir: http://msdn.microsoft.com/en-us/library/aa393664%28v=VS.85%29.aspx. (Ne me lancez même pas sur le fait que je dois savoir quel type de Reg une valeur nommée est juste pour obtenir ou définir sa valeur.J'ai déjà trouvé des solutions de contournement pour ce problème, mais il faut Enuming à travers la clé parent entière J'affecte chaque clé ou valeur nommée à un objet PHP avec ses propres propriétés et méthodes uniques pour gérer les fonctions de registre courantes - liste les valeurs nommées dans une clé, liste les sous-clés, ajoute/met à jour les clés et les noms Un problème que je prévois est si pendant que mon script s'exécute, un autre processus ou une action de mon code pourrait changer les chemins de registre de clés ou toutes les valeurs nommées ou les supprimer complètement, en fouillant ainsi tous les objets existants basés sur eux - un problème similaire à celui que l'on peut rencontrer en travaillant avec des objets du système de fichiers réels. Sauf avec le Registre, il n'y a pas de verrouillage. Par exemple, si je supprime une valeur nommée du registre qui était précédemment répertoriée dans un objet Contenu clé que j'ai créé précédemment, cet objet Contenu clé peut se trouver et me dire quand même que la valeur nommée existait. Ou, si je change la valeur de quelque chose qu'un autre processus a déjà supprimé ou déplacé, cela créerait ou écraserait quelque chose dans le registre, ce qui pourrait potentiellement endommager mon système d'exploitation. La question est, sachant que les clés et les valeurs nommées peuvent changer sans préavis, quel motif de conception OO est le meilleur pour travailler avec le Registre (ou les objets du système de fichiers d'ailleurs)?

Éditer: Je pense que je vais changer un peu. Au lieu d'avoir partout des valeurs nommées errantes en tant qu'objets séparés, je vais les faire en tant que propriétés de leur objet clé parent. Chaque valeur nommée aura une référence interne à son objet clé parent pour obtenir son chemin courant (en croisant les doigts cela ne causera pas de fuites de mémoire ou de problèmes de récursion infinie). Voici l'idée de base ...

$key->value($name_or_index)->name; // get or set name 
$key->value($name_or_index)->type; // get or set type 
$key->value($name_or_index)->value; // get or set value 
$key->value($name_or_index)->delete(); // delete this value, then destroys itself 
$key->add_value($new_name, $reg_type, $value); 
$key->parent; // get or set parent key path 
$key->name; // get or set name 
$key->delete(); // deletes key, unsets all child objects, nulls itself out 
Reg::add_key($path); // abstract factory API returning new key as object 
Reg::get_key($path); // abstract factory API returning existing key as object 

Reg master class détient également l'interface COM statique unique accessible par tous les autres objets, et est ce que toutes les autres classes sont dérivées de. Je suppose qu'il peut également contenir toutes les méthodes pour interagir directement avec le Registre, et toutes les méthodes de journalisation/de sécurité. En ce sens, ce serait une API d'usine abstraite, et laissez-moi garder les autres classes dérivées plutôt petites. Comme MainMa suggéré ci-dessous, n'importe quel accès d'une clé ou d'une valeur obtiendra des valeurs directement du Registre pour éviter tout comportement de "cache" indésirable. Et, je vais avoir un fichier .reg sécurisé au démarrage de WIN pour représenter les transactions incomplètes écrites par mon script. Si mon script se termine avec succès, il supprimera ce fichier .reg et l'entrée de démarrage à la fin. Sinon, si la puissance est coupée à mi-parcours, je devrais être en sécurité.

Je suppose que c'est le meilleur design ...? Pourquoi ne pas charger les données «sur demande»?

Answer 1

Accédez à une liste de nœuds enfants ou à un seul nœud lorsque vous en avez besoin. Éviter les données préchargées ou les données chargées trop tôt réduira le nombre d'entrées obsolètes.

Étant donné que les entrées obsolètes peuvent encore exister (ie. Si vous avez chargé la liste des enfants nœuds 1 ms il y a., Il n'y a aucune garantie que chaque enfant est toujours là), revérifier la validité des données à chaque modification.Par exemple, si vous êtes:

1. La lecture de la liste des nœuds enfants, puis
2. recherche dans la liste pour un nœud, puis,
3. pour chaque noeud correspondant, en remplaçant une valeur,

vous ne pouvez pas vérifier les données valides au second état, mais vous DEVEZ vérifier si le noeud existe au troisième état, avant de remplacer une valeur. Si la vérification échoue, lancez une exception.

Il n'y a rien de tel que transactions pour le Registre. Mais vous pouvez essayer de faire quelque chose de similaire, beaucoup plus basique, en fonction du contexte. Si vous enregistrez des clés dans le registre et que vous devez vous assurer que ces clés ne sont pas modifiées entre-temps, enregistrez les valeurs existantes, démarrez l'enregistrement et, lorsque vous avez terminé, revérifiez les valeurs. Si elles sont erronées, revenir à l'état précédent (en conservant ainsi les valeurs modifiées par un autre programme pendant la transaction).

Vous pouvez également rechercher d'autres stratégies, toujours en fonction du contexte. Par exemple, si vous déplacez un certain nombre de clés de registre d'un endroit à un autre et que vous savez que ces clés peuvent être modifiées ou supprimées entre-temps, ou revérifiez il reste des clés pour se déplacer (c'est-à-dire les nouvelles), déplacer les nouvelles, revérifier, etc.