Mise en cache les valeurs calculées de sommes / (totaux) dans la base de données

voix
0

Considérons le modèle d'objet suivant (- >> indique la collection):

> Commandes du Client,

Commandes - >> OrderLineItems-> Produit {Prix}

L'application se concentre sur le traitement des commandes, de sorte que la plupart des tables de temps montrant toutes les commandes qui correspondent à certains critères sont utilisés dans l'interface utilisateur. 99% du temps, je ne suis intéressé que l'affichage de la somme des LineTotals, pas les LineTotals individuels.

En y repensant plus loin, on peut aussi avoir plusieurs paiements (virements, chèque, carte de crédit, etc.) associées à chaque commande, encore une fois, im seulement intéressé par la somme d'argent que je recevais.

Lorsque vous interrogez la base de données pour une commande, je ne veux pas sélectionner toutes les commandes et, pour chaque commande, ses paiements et LineItems.

Mon idée était de stocker l'associé chaque commande avec un « statut » objet, la mise en cache toutes les sommes et le statut d'une commande, l'amélioration des performances des requêtes par des ordres de grandeur et de soutenir des scénarios de requête pour les commandes impayées, payé les commandes, les commandes à cause, etc.

Cela empêche la logique de domaine (par exemple, lorsqu'un ordre est considéré comme payant) de fuir dans les requêtes de base de données. Cependant, il met la responsabilité de garder les sommes à jour. Le système a généralement des points bien définis où cela doit se produire, par exemple l'entrée ou l'intégration des paiements, créer / modifier un ordre.

Jusqu'à présent, je l'ai utilisé, Collections Observable qui déclenchent recalcul de statut lorsque des éléments sont ajoutés ou supprimés, ou certaines propriétés sur les articles sont mis à jour. Je me demande où la logique de tout ce qui doit être mis dans une perspective de ddd. Il me semble étrange de forcer tout le câblage de l'événement et la logique de calcul à la racine globale.

Créé 26/08/2009 à 23:45
source utilisateur
Dans d'autres langues...                            


3 réponses

voix
1

Vous avez besoin d'exprimer l' intention d'une demande dans une interface révélant l' intention, afin que vos dépôts peuvent comprendre exactement ce que vous voulez faire et de réagir en conséquence. Dans ce cas , l'interface révèle l' intention, et non pas à d' autres développeurs, mais à tout autre code. Donc , si vous voulez un statut ou totale, créer une interface qui révèle cette intention et demander un objet de ce type de votre référentiel. Le dépôt peut alors créer et retourner un objet de domaine qui encapsule faire exactement le travail requis pour calculer le total et pas plus que cela.

En outre, votre DAL peut choisir intelligemment quelle stratégie fetching d'appliquer à partir de l'interface que vous demandez, par exemple le chargement paresseux pour les situations où vous n'avez pas besoin d'accéder aux objets de l'enfant et le chargement désireux où vous faites.

Udi Dahan a quelques grands messages de blog au sujet de cette . Il a écrit et parlé sur l' application des interfaces révélant intention à ce problème, qu'il appelle faire des rôles explicites .

Créé 03/09/2009 à 23:55
source utilisateur

voix
0

« Il me semble étrange de forcer tout le câblage de l'événement et la logique de calcul à la racine globale. »

C'est généralement un appel pour un «service».

Créé 15/09/2009 à 22:24
source utilisateur

voix
0

Je recommande fortement de voir cartographes OU (relationnelle de l'objet) qui prennent en charge LINQ. Pour nommer les deux principales, LINQ to SQL et Entity Framework, tous deux de Microsoft. Je crois LLBLGen prend également en charge LINQ maintenant, et NHibernate a quelques solutions de LINQ demi-cuite au four, vous pouvez essayer. Ma principale recommandation est Entity Framework v4.0, qui est disponible via .NET 4.0 bêtas ou Visual Studio 2010 Beta.

Avec un LINQ activé ou mappeur, vous pouvez facilement interroger pour l'information globale dont vous avez besoin dynamiquement, en temps réel, en utilisant uniquement votre modèle de domaine. Il n'y a pas besoin de logique d'affaires à fuir dans votre couche de données, parce que vous généralement pas utiliser des procédures stockées. OU cartographes générer des requêtes SQL paramétrées pour vous à la volée. LINQ combinés aux cartographes est un outil extrêmement puissant qui vous permet non seulement de requête et récupérer des entités et des graphiques d'entités, mais aussi interroger des projections de données sur votre modèle de domaine ... permettant la récupération des ensembles de données sur mesure, agrégations, etc. par l'intermédiaire d'un seul modèle conceptuel.

Créé 27/08/2009 à 07:56
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more