MISE À JOUR sur un objet de domaine qui a été créé avec un JOIN

Comment cette situation est-elle généralement gérée? J'ai un objet de domaine qui contient des données qui sont le résultat d'une jointure entre 2 tables; comment la mise à jour doit-elle être gérée? Une approche consiste à avoir TableADao, TableBDao (relation 1to1 table-Dao) et avoir l'objet domaine construit par une classe Repository qui gère efficacement la relation (joindre & mise à jour par lots).MISE À JOUR sur un objet de domaine qui a été créé avec un JOIN

Y a-t-il un meilleur moyen? L'utilisation d'un JOIN semble beaucoup plus efficace. Les 2 tables sont très petites, mais font partie d'une ancienne DB que je dois supporter & ne peut pas changer.

Comment ORM gérer ce scénario?

Source

2011-04-28 Stoney

Créez une vue et vous pouvez la mettre à jour comme s'il s'agissait d'une table.

Source

2011-04-28 04:37:22

cela résoudrait certainement mon problème, mais je me demande comment cela fonctionnera avec l'exigence no DB modifications. Est-ce que je peux faire ceci d'une manière qu'ils sont jetables, par exemple. un Dao crée la vue à l'instanciation puis la supprime après avoir été détruite? Cette implémentation db est-elle également spécifique? En ce moment, je ne supporte que l'oracle 10/11g, mais supportera éventuellement MSSQL, MySql, et j'espère que nous pourrons être proche de l'implémentation complètement DB – Stoney

Je ne suis pas sûr, vous pouvez demander sur dba.stackexchange.com –

Cela dépend de l'ORM que vous utilisez. Il peut ou non prendre en charge des objets agrégés et/ou des vues mappées.

Source

2011-04-28 12:22:32

Malheureusement (ou peut-être pas, comme je continue à lire sur la façon dont ORM sont vraiment pas cool, au moins du point de vue d'un administrateur de base de données) je ne peux pas utiliser un vrai ORM en raison de la mauvaise conception de base de données. Plus précisément, une fois déployé, il doit être capable de gérer les modifications du schéma de base de données qui ne sont pas de bon augure pour les mappages de domaine db-> statiques. À l'heure actuelle, j'utilise Apache DBUtils avec un résolveur personnalisé qui mappe des cols connus sur les propriétés du bean, jette tout le reste dans une carte et s'appuie sur des méthodes d'accès sécurisées pour empêcher les NPE. – Stoney

Chaque fois qu'un schéma db change, il ne devrait pas provoquer de changements de code dans le code existant, n'est-ce pas ...? Si des tables sont ajoutées, les ORM peuvent gérer cela. Si les champs sont ajoutés ou renommés, les ORM peuvent gérer cela aussi. Fondamentalement, tout changement peut être géré ou couvert en utilisant des vues. Mais le fait demeure que la maintenance des applications héritées crappy sucent: - / –

MISE À JOUR sur un objet de domaine qui a été créé avec un JOIN

Répondre

Questions connexes