Initialisation du constructeur à partir du cache stocké en C#

Question

Je ne sais pas exactement comment décrire cette question, mais voilà. J'ai une hiérarchie de classe d'objets qui sont mappés dans une base de données SQLite. J'ai déjà écrit tout le code non-trivial qui communique entre les objets .NET et la base de données.

J'ai une interface de base comme suit:

public interface IBackendObject 
{ 
    void Read(int id); 
    void Refresh(); 
    void Save(); 
    void Delete(); 
} 

Ce sont les opérations CRUD de base sur tout objet. J'ai ensuite implémenté une classe de base qui encapsule la plupart des fonctionnalités.

public abstract class ABackendObject : IBackendObject 
{ 
    protected ABackendObject() { } // constructor used to instantiate new objects 
    protected ABackendObject(int id) { Read(id); } // constructor used to load object 

    public void Read(int id) { ... } // implemented here is the DB code 
} 

Maintenant, enfin, j'ai mes objets enfants en béton, dont chacun ont leurs propres tables dans la base de données:

public class ChildObject : ABackendObject 
{ 
    public ChildObject() : base() { } 
    public ChildObject(int id) : base(id) { } 
} 

Cela fonctionne bien pour tous mes objectifs jusqu'à présent. L'enfant dispose de plusieurs méthodes de rappel utilisées par la classe de base pour instancier correctement les données.

Je veux maintenant rendre cela un peu efficace. Par exemple, dans le code suivant:

public void SomeFunction1() 
{ 
    ChildObject obj = new ChildObject(1); 
    obj.Property1 = "blah!"; 
    obj.Save(); 
} 

public void SomeFunction2() 
{ 
    ChildObject obj = new ChildObject(1); 
    obj.Property2 = "blah!"; 
    obj.Save(); 
} 

Dans ce cas, je serai construire deux instanciations de mémoire complètement nouveaux et en fonction de l'ordre de SomeFunction1 et SomeFunction2 appelés, soit Propriété1 ou Propriété2 ne peuvent pas être sauvés. Ce que je veux réaliser est un moyen pour ces deux instanciations de pointer d'une manière ou d'une autre vers le même emplacement de mémoire - je ne pense pas que ce sera possible si j'utilise le "nouveau" mot-clé, donc je cherchais des indices la façon de procéder. Idéalement, je voudrais stocker un cache de tous les objets chargés dans ma classe ABackendObject et renvoyer des références de mémoire aux objets déjà chargés lorsque demandé, ou charger l'objet de la mémoire si elle n'existe pas déjà et l'ajouter à la cache. J'ai beaucoup de code qui utilise déjà ce framework, donc je vais bien sûr devoir changer beaucoup de choses pour que cela fonctionne, mais je voulais juste quelques conseils sur la façon de procéder.

Merci!

Answer 1

Si vous souhaitez stocker un "cache" d'objets chargés, vous pouvez facilement faire en sorte que chaque type maintienne un Dictionary<int, IBackendObject> qui contient les objets chargés, chiffrés par leur ID.

Au lieu d'utiliser un constructeur, construire une méthode d'usine qui vérifie le cache:

public abstract class ABackendObject<T> where T : class 
{ 
    public T LoadFromDB(int id) { 
     T obj = this.CheckCache(id); 
     if (obj == null) 
     { 
      obj = this.Read(id); // Load the object 
      this.SaveToCache(id, obj); 
     } 
     return obj; 
    } 
} 

Si vous faites votre classe de base générique et de lecture virtuelle, vous devriez être en mesure de fournir plus de cette fonctionnalité sans beaucoup duplication de code.

Answer 2

Ce que vous voulez est une usine d'objets. Rendez le constructeur ChildObject privé, puis écrivez une méthode statique ChildObject.Create(int index) qui renvoie un ChildObject, mais qui garantit en interne que les différents appels avec le même index renvoient le même objet. Pour les cas simples, un hachage statique simple de l'index => objet sera suffisant.

Answer 3

Si vous utilisez .NET Framework 4, vous pouvez jeter un oeil à l'espace de noms System.Runtime.Caching, ce qui vous donne une architecture cache assez puissante.

http://msdn.microsoft.com/en-us/library/system.runtime.caching.aspx

Answer 4

sons parfait pour un compte de référence comme celui-ci ...

#region Begin/End Update 
    int refcount = 0; 
    ChildObject record; 
    protected ChildObject ActiveRecord 
    { 
     get 
     { 
      return record; 
     } 

     set 
     { 
      record = value; 
     } 
    } 

    public void BeginUpdate() 
    { 
     if (count == 0) 
     { 
      ActiveRecord = new ChildObject(1); 

     } 

     Interlocked.Increment(ref refcount); 
    } 

    public void EndUpdate() 
    { 
     int count = Interlocked.Decrement(ref refcount); 

     if (count == 0) 
     { 
      ActiveRecord.Save(); 
     } 
    } 
    #endregion 


    #region operations 

    public void SomeFunction1() 
    { 
     BeginUpdate(); 

     try 
     { 
      ActiveRecord.Property1 = "blah!"; 
     } 
     finally 
     { 
      EndUpdate(); 
     } 
    } 

    public void SomeFunction2() 
    { 
     BeginUpdate(); 

     try 
     { 
      ActiveRecord.Property2 = "blah!"; 
     } 
     finally 
     { 
      EndUpdate(); 
     } 
    } 


    public void SomeFunction2() 
    { 
     BeginUpdate(); 

     try 
     { 
      SomeFunction1(); 
      SomeFunction2(); 
     } 
     finally 
     { 
      EndUpdate(); 
     } 
    } 
    #endregion 

Answer 5

Je pense que votre sur la bonne voie plus ou moins. Vous pouvez créer une fabrique qui crée vos objets enfants (et suivre les instances "en direct"), ou vous pouvez suivre les instances qui ont été enregistrées, de sorte que lorsque vous appelez votre méthode Save, elle reconnaît que votre première instance est ChildObject le même que votre deuxième instance de ChildObject et fait une copie profonde des données de la deuxième instance sur le premier. Les deux sont relativement non triviaux du point de vue du codage, et les deux impliquent probablement de remplacer les méthodes d'égalité sur vos entités. J'ai tendance à penser que l'utilisation de la première approche serait moins susceptible de causer des erreurs.

Une option supplémentaire consisterait à utiliser un package de mappage Obect-Relationnel existant tel que NHibernate ou Entity Framework pour effectuer votre mappage entre des objets et votre base de données. Je sais que NHibernate prend en charge Sqlite et, d'après mon expérience, a tendance à être celle qui nécessite le moins de changements dans les structures de votre entité. En suivant cette route, vous bénéficiez des instances de suivi de couche ORM pour vous (et générez du SQL pour vous), plus vous obtiendrez probablement des fonctionnalités plus avancées que votre code d'accès aux données actuel peut ne pas avoir. L'inconvénient est que ces cadres ont tendance à avoir une courbe d'apprentissage qui leur est associée, et en fonction de ce que vous allez avec, il pourrait y avoir un impact non négligeable sur le reste de votre code. Il serait donc utile de peser les avantages par rapport au coût d'apprentissage de l'infrastructure et de convertir votre code pour utiliser l'API.