l'application en couches à trois niveaux en utilisant Wicket + Spring + Hibernate. Comment voulez-vous gérer les transactions?

Question

Je pense à l'aide de la Open Session in View (OSIV) filtre ou intercepteur qui vient avec le printemps, comme il semble comme un moyen pratique pour moi en tant que développeur. Si c'est ce que vous recommandez, recommandez-vous à l'aide d'un filtre ou un intercepteur et pourquoi?

Je demande aussi comment il va mélanger avec HibernateTemplate et si je vais perdre la capacité de marquer des méthodes comme @Transactional (readOnly = true) etc et donc perdre la capacité d'obtenir un contrôle des transactions à grain plus fin?

Y at-il une sorte de meilleures pratiques pour la façon d'intégrer ce genre de solution avec une architecture à trois niveaux en utilisant Hibernate et Spring (comme je suppose que ma décision d'utiliser Wicket pour la présentation ne devrait pas beaucoup d'importance)?

Si je OSIV je au moins jamais courir dans des exceptions de chargement paresseux, d'autre part ma transaction va vivre plus longtemps avant de pouvoir engager en étant non engagée dans la vue aussi bien.

Answer 1

Il est vraiment une question de goût personnel.

Personnellement, j'aime avoir des limites de transaction à la couche de service. Si vous commencez à penser SOA, chaque appel à un service doit être indépendant. Si votre couche de vue doit appeler 2 services différents (on pourrait dire que ce qui est déjà une odeur de code), alors ces 2 services doivent se comporter indépendamment les uns des autres, pourrait avoir des configurations différentes de transaction, etc ... Avoir aucune transaction ouverte en dehors du services contribue également à faire en sorte qu'aucune modification se produit en dehors d'un service.

OTOH vous devrez penser un peu plus sur ce que vous faites dans vos services (chargement paresseux, des fonctionnalités regroupement dans la même méthode de service si elles ont besoin d'un transactionnalité commun, etc ...).

Un modèle qui peut aider à réduire les erreurs de chargement paresseux est d'utiliser la valeur objet en dehors de la couche de service. Les services doivent toujours charger toutes les données nécessaires et copier BÉNÉVOLES. Vous perdez la mise en correspondance directe entre vos objets persistants et votre couche de vue (ce qui signifie que vous devez écrire plus de code), mais vous trouverez peut-être que vous gagnez en clarté ...

Modifier La décision sera basée sur des arbitrages, donc je pense toujours que ce soit au moins en partie une question de goût personnel. Transaction à la couche de service se sent me plus propre (plus SOA comme, la logique est clairement retenu à la couche de service, les différents appels sont clairement séparés, ...). Le problème avec cette approche est LazyLoadingExceptions, qui peut être résolu en utilisant VO. Si VO sont juste une copie de vos objets persistants, alors oui, il est clairement une rupture du principe DRY. Si vous utilisez VO comme vous utiliseriez une vue base de données, puis VO sont une simplification de vous objets persistants. Il sera encore plus de code à écrire, mais il fera de votre conception plus claire. Il devient particulièrement utile si vous avez besoin de brancher un certain régime d'autorisation. Si certains champs ne sont visibles que pour certains rôles, vous pouvez mettre l'autorisation au niveau de service et de ne jamais renvoyer des données qui ne doivent pas être vues

Answer 2

  

Si je OSIV je vais au moins jamais   courir dans les exceptions de chargement paresseux

ce n'est pas vrai, en fait, son très facile à exécuter dans le LazyInitializationException infâme, il suffit de charger un objet, et essayer de lire un attribut de celui-ci, après la vue, en fonction de votre configuration, vous obtiendrez le LIE