Architecture logicielle: Unité de modèle de conception de travail discussion

Question

Selon l'unité de Martin Fowler Description du travail:

« Maintient une liste d'objets qui sont affectés par une transaction commerciale et coordonne l'écriture sur les changements et résolution des problèmes de concurrence . "

Éviter

appels très petite à la base de données, qui finit par être très lent

Je me demande. Si nous limitons simplement à la gestion des transactions de base de données, les instructions de préparation ne seront-elles pas utiles?

Answer 1

Les instructions préparées n'ont rien à voir avec les transactions. Ce à quoi Fowler se réfère est la latence du réseau: si vous allez dans la base de données, vous encourrez un délai réseau à chaque fois.

Cette question a deux idées confondues: les transactions et les lots. Le fait de regrouper plusieurs opérations de base de données et de les envoyer toutes à la base de données à traiter peut également répondre à ce dont Fowler parle.

Lequel vous souciez-vous vraiment ici?

Answer 2

Une bonne implémentation de la couche d'accès aux données le fera pour vous. Par exemple, Hibernate/NHibernate peut différer les modifications de vidage jusqu'à la fin de la transaction ou lorsque vous demandez explicitement des modifications à supprimer. Vous pouvez également récupérer les données dans une transaction et stocker les modifications dans une autre, en utilisant le verrouillage optimiste. Cela évite les longues transactions de base de données.

Si vous lancez votre propre couche d'accès, vous pouvez ajouter un traitement par lots à la connexion JDBC pour réduire le temps de latence de nombreuses petites demandes de mise à jour/insertion. Même ainsi, je pense que ce modèle est une bonne idée, car il donne un bon aperçu de tous les changements dans un endroit. Vous pouvez donc soumettre toutes vos modifications en même temps, rapidement dans une transaction de base de données, plutôt que d'écrire sur la base de données étalée sur la durée de la transaction commerciale, ce qui peut être long et les transactions longue durée ne sont généralement pas bonne idée. PreparedStatements sont orthoganal à ce modèle - ils n'aident pas ou n'entravent pas directement. Le modèle consiste à réduire la latence du réseau et à avoir des transactions courtes, ainsi qu'à avoir une vue d'ensemble de tous les changements d'entité dans une opération commerciale.

Answer 3

Le modèle est plus général que les bases de données. Chaque fois que vous pouvez regrouper plusieurs petites opérations en une, le modèle d'unité de travail peut être applicable. Par exemple, pensez à une application AJAX, dans laquelle vous souhaitez informer le serveur de certaines opérations que vous avez effectuées sur le client. Vous pouvez regrouper ces opérations en une seule opération plus importante. Le serveur peut ou ne peut pas transmettre les données à une base de données. Du côté serveur, une unité de travail peut devoir enregistrer des données dans la base de données et les transmettre à un autre client travaillant avec les mêmes données.La principale chose à noter est qu'une «transaction commerciale» et une transaction DB sont deux choses différentes.