Chargement paresseux des champs DTO au printemps

Question

J'ai un projet qui utilise Spring et qui est divisé en une vingtaine de DAO et DTO associés. J'utilise JdbcTemplate, mais pas grand-chose d'autre, car c'est exactement le niveau d'abstraction dont je suis satisfait.

Je charge actuellement mes DTO en plaçant du code plutôt poilu dans leurs getters.

La logique standard de base est la suivante: 1. Si le champ n'est pas nul, retourne sa valeur et quitte 2. Contacter le DAO approprié et aller chercher les DTO pertinents 3. Rangez-les jusqu'à la prochaine fois.

Cela fonctionne très bien, sauf que mes modestes DTO sont associés à de nombreux DAO et ne le sont pas autant.

Une autre odeur de code apparaît si je place la logique dans le DAO, car il gérerait à la fois CRUD pour ses DTO et le chargement différé. D'après ce que je comprends, les objets devraient avoir une responsabilité unique.

J'espère qu'il est possible d'utiliser une approche Spring relativement simple pour injecter un objet Lazy Loader entre les DAO et les DTO, mais toute autre solution fonctionnerait pour moi.

Des idées?

Answer 1

Il est plus facile d’enrouler les DAO autour de ceux-ci ... tout dépend du modèle que vous souhaitez présenter. Les DTO ne sont généralement pas utilisés pour amener un à plusieurs avec eux, comme deux ou plusieurs appels séparés de base de données / dao. Dans ce cas, vous voulez vraiment un ORM. Depuis que tu cherches une réponse dao ......

Rien ne vous empêche de lier les DAO pour vous donner un seul DTO. Il est alors plus facile de connecter un DTO à un DAO. Ce n'est pas vraiment une couche de service, c'est juste des blocs de construction de DAO. Donc, vous pourriez avoir un PersonDao, et un TelephoneNumberDao. Une personne peut avoir plus d'un numéro de téléphone, vous pouvez donc également utiliser PersonModelDAo, qui utilise PersonDao et TelephoneNumberDao sous le capot pour effectuer son travail.

Sinon, évitez tout le problème et n'essayez pas de mapper le 1-N entre la personne et le numéro de téléphone au niveau du DTO. Demandez à votre interface utilisateur d’appeler correctement les DAO appropriés. En fait, j'aime mieux cela quand j'utilise des DTO.

Answer 2

Il est courant d'introduire une couche de service qui enveloppe vos DAO et gère les problèmes de ce type. Si vous craignez d'introduire trop de code standard dans vos DTO pour gérer le chargement paresseux, peut-être qu'utiliser AOP pourrait être un moyen d'y parvenir. Vous voudrez peut-être examiner AspectJ et le tissage au moment de la compilation ou du chargement. Étant donné que vous modifieriez directement le code d'octet, vous ne devriez pas vous inquiéter des frais généraux liés aux performances d'un système AOP basé sur un proxy.