DAO modèle de conception, et de l'utiliser sur plusieurs tables

Je suis à la recherche de commentaires sur le L'Accès Aux Données De L'Objet modèle de conception, et de l'utiliser quand vous avez accès à des données provenant de plusieurs tables. Il semble que ce modèle, qui a un DAO pour chaque table avec un Objet de Transfert de Données (DTO) qui représente une ligne unique, n'est pas trop utile pour lorsque vous traitez avec des données provenant de plusieurs tables. Je pensais à la création d'un composite DAO et correspondant DTO qui retourne le résultat, disons effectuer une jointure sur deux tables. De cette façon, je peux utiliser SQL pour récupérer toutes les données au lieu de la première accaparement des données de l'un à l'aide de l'un de DAO et de la deuxième table à l'aide de la deuxième DAO, et de composer ensemble en Java.

Est-il une meilleure solution? Et non, je ne suis pas en mesure de se déplacer à Hibernate ou un autre outil ORM pour le moment. Tout droit JDBC pour ce projet.

OriginalL'auteur Casey | 2010-03-24

  1. 12

    Je suis d'accord avec votre approche. Mon DAOs ont tendance à être aligné plus au niveau de l'objet, plutôt que de partir d'une base de Table point de vue. Je peux gérer plus d'un objet par l'intermédiaire d'un DAO, mais ils seront très probablement être étroitement liées. Il n'y a aucune raison de ne pas disposer de SQL accès à deux tables de la vie dans un DAO.

    Et pour l'enregistrement, j'ai banni l'acronyme DTO de mon vocabulaire et mon code.

    "J'ai banni l'acronyme DTO de mon vocabulaire et mon code." Pouvez-vous expliquer plus?
    Je ne vois pas l'intérêt d'appeler un objet d'un Transfert de Données de l'Objet. Je peupler d'objets de domaine directement dans mon DAOs, les utiliser de mes services, et de les exposer dans mon point de vue (parfois je peut créer d'autres objets de vue). Otd n'ont généralement aucun problème, et sont muets titulaires de droits de propriété. Je ne vois pas de raison de limiter mes objets dès lors dans un cadre moderne Java architecture de projet. Et modernes, en général, je veux dire non-EJB, avec un cadre comme le Printemps.
    Je vois. Peu de la même manière que je les utiliser. Merci.
    Est-ce une meilleure pratique? Ainsi, dans un DAO, vous auriez getWhatever() qui appelle getSomethingElse() pour construire Quoi que ce soit. J'ai l'impression que c'est de commettre des erreurs, parce que l'ordre est très important à la fois l'insertion et la mise à jour.
    Pouvez-vous donner un exemple de pourquoi c'est de commettre des erreurs? Je vais avoir un moment difficile de les visualiser.

    OriginalL'auteur pkananen

  2. 3

    Idéalement, la façon dont vous stockez vos données dans une base de données, puis comment vous y avez accès, doit être dérivé de la nature de la relation entre le domaine des entités dans le modèle de domaine. C'est, Modèle Relationnel devraient suivre de Modèle de Domaine. Par exemple, si vous avez deux entités, disons, de l'Utilisateur et de l'Adresse.

    Scénario #1: Adresse ne sont jamais consulté de façon indépendante, ils sont toujours un attribut de l'Utilisateur.
    Dans ce cas, l'Adresse est une Valeur de l'Objet et l'Utilisateur est une Entité, et il y a des guides sur la façon de stocker cette relation. Une façon est de stocker les attributs d'Adresse de l'Adresse aux côtés des attributs de l'Utilisateur, dans un tableau unique. Dans ce cas, UserDao permettra de gérer à la fois des objets.

    Scénario #2: Adresse peut être associé à un Utilisateur, mais aussi peut être séparé sur son propre, une entité.
    Dans ce cas, une approche différente de la première, est nécessaire. Vous pouvez avoir une DAO et une table pour le type d'Adresse.

    Mon point est, que le plus souvent cette idée importante est la non prise en compte du Modèle de Domaine doit être le noyau de l'application, la conduite d'autres couches.

    Par exemple, si votre modèle de domaine est de définir correctement et que vous êtes bien au courant de la nature des entités que vous avez et la relation entre eux, puis de persistance (tables relationnelles et de leurs relations, de votre DAOs, etc) vont évoluer comme une conséquence logique de ce que vous avez dans le modèle de domaine.

    En d'autres termes, si vous passez un certain temps à l'étude de votre modèle, vous serez en mesure de retracer votre problème de savoir comment organiser votre DAOs pour une place dans le modèle de domaine. Si vous pouvez définir clairement le type des objets et de la nature de la relation entre eux dans le modèle de domaine, il sera, de vous aider à résoudre votre problème dans la couche DAL.

    OriginalL'auteur Nazar Merza