Il me vient à l'esprit que le contrôle d'état dans des langages comme C# n'est pas bien pris en charge. Je veux dire par là que le programmeur doit gérer l'état des objets en mémoire. Un cas d'utilisation courant est que les variables d'instance dans le modèle de domaine sont des copies d'informations résidant dans un stockage persistant (c'est-à-dire la base de données). De toute évidence, cela viole le principe du point d'autorité unique, et la «synchronisation» doit être gérée par le développeur. Je prévois un système où au lieu de variables d'instance, nous avons des méthodes simples d'accès public/mutateur marquées avec des attributs qui les relient à la base de données, et où les lectures et les écritures sont médiées par un cadre qui décide de frapper la base de données. Un tel système existe-t-il? Est-ce que je manque complètement le point ou y a-t-il une part de vérité dans cette idée?Est-ce que quelqu'un d'autre pense que les variables d'instance sont problématiques dans les applications basées sur une base de données?
Répondre
Si je comprends bien ce que vous voulez: Tout OR-Mapper avec Lazy Loading fonctionne de cette façon. Par exemple j'utilise Genome et là chaque entité est un proxy pur et vous avez beaucoup d'influence pour dire à l'OR-Mapper comment mettre en cache les champs.
En fait, il existe le concept de prévalence des données (implémenté par prevayler en Java) où les objets en mémoire sont le point d'autorité unique (SPA) pour les données.
De plus, certaines bases de données d'objets (comme db4o) floutent des lignes un peu entre la représentation de l'objet et la représentation de "stockage". D'autre part, en apportant le SPA pour les données dans l'application, vous devez gérer vous-même les transactions et/ou la persistance des données. Il y a du travail sur les systèmes de mémoire transactionnelle tels que JVSTM (actuellement utilisé par le système d'information de mon ancien collège) mais il n'est pas très répandu. D'un autre côté, si les données résident dans une base de données, vous pouvez valider les données quand tout est bon (ou utiliser le support pour les transactions intégrées dans la base de données) et être sûr que les données ne sont pas corrompues . Vous négociez le principe du SPA pour une meilleure fiabilité des données et transactions (et d'autres avantages de l'utilisation d'un magasin de données séparé)