2009-04-15 8 views
4

Je suis peut-être condamné par une incompatibilité d'impédance, mais j'essaie de réconcilier des exemples que j'ai vus pour IRepository et des objets immuables.Dépôt et objets immuables?

Je travaille sur une application de catalogage où des centaines de requêtes Web fonctionnent sur un 'ensemble de travail' de produits - un sous-ensemble du catalogue entier a tendance à être en jeu à un moment donné.

En même temps, nos équipes de données constamment mise à jour des données de produit - de nouvelles images, les prix mis à jour, descriptions, etc., etc.

Il me semble que pour la performance que je suis mieux considérer un produit comme immuable . Ils sont chargés et mis en cache par un référentiel et de nombreux threads peuvent accéder au même objet produit en même temps. Mais cette idée semble rompue avec de nombreux exemples IRepository que j'ai vus avec les méthodes Update/Delete - dès qu'un thread peut écrire sur un produit, il semble que je m'ouvre aux courses et à d'autres problèmes. J'ai donc imaginé un modèle «éditeur» où les modifications apportées à une entité sont effectuées via un objet «éditeur» compagnon qui persiste alors les modifications et force le produit en question à être rechargé pour que tout le monde puisse l'utiliser. Les produits ne sont jamais modifiés - seulement 'édités' en externe et rechargés.

Est-ce que cela a un sens? Est-ce que cela peut fonctionner avec un référentiel tel que je les ai vus décrits?

Merci pour votre temps!

Répondre

4

Un référentiel est uniquement responsable de la récupération/du stockage de données. Une usine est responsable de la création de nouveaux objets.

Dans votre cas, les objets immuables sont corrects. Cependant, vous avez besoin d'une méthode pour invalider les produits remplacés et les supprimer du cache du référentiel. Toutes les références qui pendent peuvent être négligées dans la plupart des cas, car elles étaient valables au moment de la récupération.

En cas de mise à jour du produit, vous devez vous assurer que vous avez créé un nouveau produit en usine. Votre référentiel ne comprend que trois types d'opérations: Retrieve (ou Find), Save et Supersede. Où Enregistrer stocke un nouveau produit, qui n'est pas modifié. Et Supersede stockerait le nouveau produit, invaliderait l'ancien et le purgerait du cache.

En ce qui concerne une signature C# je pourrais imaginer les deux méthodes de stockage pour prendre l'aspect suivant:

void Save(Product product); 

void Supersede(Product oldProduct, Product newProduct); 

J'espère que cela aide.

+0

Peut-être que cela avec un «edit lock» comme suggéré par Michael Haren est la voie à suivre - merci beaucoup! – n8wrl

+0

Je ne suis pas sûr si je voudrais vraiment mettre à jour l'enregistrement de base de données pour le produit. Si vous devez conserver un historique de produit, il peut être plus judicieux de le remplacer. – grover

1

Existe-t-il des exigences de concurrence ou de performances si élevées que vous ne pouvez pas effectuer de verrouillage simple, soit exclusif/pessimiste ou optimistic?