Pourquoi tant de programmeurs détestent-ils absolument les couches de prévalence d'objets?

La prévalence est une technique simple pour fournir des propriétés ACID à un modèle d'objet en mémoire basé sur la sérialisation binaire et la journalisation en écriture anticipée. Cela fonctionne comme ceci:

• Commencez avec un instantané. Sérialisez le modèle d'objet et écrivez-le dans un fichier.
• Créez un fichier journal. Pour chaque appel dans le modèle objet, sérialisez l'appel et ses arguments.
• Lorsque le journal devient trop volumineux, vous arrêtez, ou autrement c'est pratique, effectuez un point de contrôle: écrivez un nouvel instantané et tronquez le journal.
• Pour revenir en arrière ou récupérer après un crash ou une coupure de courant, chargez le dernier instantané et réexécutez tous les appels enregistrés dans le journal.

Les précautions nécessaires pour faire ce travail sont:

• Ne laissez pas les références d'objets mutables s'échapper ou entrer dans la couche de prévalence. Vous avez besoin d'une sorte de proxy ou de schéma OID, comme si vous faisiez du RPC. (C'est une erreur si courante pour les débutants qu'elle a été surnommée le `` problème du baptême ''.)
• Toute la logique accessible à partir d'un appel doit être complètement déterministe et ne doit pas effectuer d'appels d'E / S ou de système d'exploitation significatifs pour la logique métier. L'écriture dans un journal de diagnostic est probablement OK, mais l'obtention de l'heure système ou le lancement d'un délégué asynchrone ne l'est généralement pas. Il en est ainsi que le journal est relu à l'identique même s'il est restauré sur une machine différente ou à un moment différent. (La plupart des codes de prévalence fournissent un autre appel horaire pour obtenir l'horodatage de la transaction.)
• La simultanéité des écrivains introduit une ambiguïté dans l'interprétation des revues, elle est donc interdite.

Est-ce parce que ...

• les gens ont développé un mauvais goût pour eux après avoir essayé d'en utiliser un sur un projet qui ne leur convenait pas ^* ?
• Le plaidoyer strident de Klaus Wuestefeld a rebuté les gens ?
• les gens qui aiment le modèle de programmation impératif n'aiment pas séparer les E / S du calcul , préférant plutôt entrelacer le calcul avec les E / S et les appels de thread?
• les couches de prévalence sont si conceptuellement simples et si intimement liées aux caractéristiques du cadre qu'elles habitent qu'elles sont généralement personnalisées pour le projet, ce qui les rend trop étrangères / non standard / risquées?
• il est tout simplement trop difficile de garder ce que vous devez faire attention à ne pas faire?
• la tête des débutants semble juste exploser face à quelque chose qui n'est pas le même type d'application basée sur une base de données à deux niveaux qu'ils ont appris à écrire à l'école? ;)

^* L' ensemble des données tient dans la RAM , vous n'avez pas besoin de la simultanéité des écrivains et vous n'avez pas besoin de faire des requêtes ad hoc, des rapports ou des exportations vers un entrepôt de données. Avec des excuses à SQLite, la prévalence est une amélioration des fichiers de sauvegarde, pas un remplacement pour Oracle.

Je pense qu'une partie du problème est qu'ils ont un cas d'utilisation TRÈS spécifique (votre raison ne convient pas). J'ai construit et travaillé sur des systèmes qui utilisent cette approche et lorsque vous avez un problème qui est en fait ce problème, cela peut être une merveilleuse solution.

Une autre partie est qu'elle ressemble beaucoup à certains des éléments de stockage de données personnalisés les plus douloureux que vous aviez l'habitude de trouver il y a plus de 10 ans et présente certains des mêmes pièges (pensez à la mise à jour par lots de btreive par exemple) qui apporte votre point "trop ​​personnalisé", mais rend également difficile de trouver des pièces sur étagère qui fonctionnent poliment avec lui.

La dernière partie est qu'ils peuvent être sacrément difficiles à interroger dans de nombreux cas et les gens en général sont assez habitués à pouvoir obtenir leurs réponses dès maintenant.

Je pense que vous devez d'abord démontrer que tant de développeurs les détestent absolument. Je ne pense pas que ce soit le cas. Considérez que l'oiseleur, il y a quelque temps, a formalisé une sorte de modèle pour cela ici .

La réponse à la question est que si la théorie est simple, la pratique ne l'est pas.

Le simple test d'une telle configuration nécessite des dizaines de cas de test, ajoutez du processus mutli ou du code multi-thread et cela passe à des centaines de conditions possibles qui doivent être testées, à la fois pour la persistance et la récupération.

Tout moniteur de transactions tel que CICS, Tuxedo, Weblogic, Websphere, JBOSS ou .NET, fournira toutes ces installations de manière propre et testée. Et n'importe quelle base de données fournira "suffisamment" de transaction / persistance pour la plupart des applications.

C'est surtout un boîtier de cette roue qui a été inventé et perfectionné il y a longtemps.

Les pré-requis semblent un peu onéreux à coder, en particulier avec la plupart des systèmes n'ayant pas besoin de la conformité ACID lors de l'exécution en mémoire. Les frais généraux semblent un peu méchants aussi - il y a beaucoup de suivi d'état impliqué.