DAO structure de paquet

Je suis en train d'écrire une simple DAOs en Java à l'aide de JDBC (pas de Spring, Hibernate ou quoi que ce soit d'autre).

Il est mieux de mettre la mise en œuvre DAOs dans le même package que leurs interfaces ou les mettre dans un sous-package?

Exemple:

com.mycompany.myproject.dao.MyDao
com.mycompany.myproject.dao.MyDaoImpl

OU

com.mycompany.myproject.dao.MyDao
com.mycompany.myproject.dao.impl.MyDaoImpl

Si vous suggèrent le sous-ensemble de la structure, que suggéreriez-vous comme un sous-nom du package? .impl? .sql? .jdbc?

De façon réaliste, je ne vais pas avoir plusieurs implémentations. Suis-je sur-le génie?

Pas d'autres implémentations? Même pas de test de l'unité se moque?

OriginalL'auteur dhalsim2 | 2012-04-02

  1. 5

    Lors de la conception d'une application, il n'y a pas de standard mode de structuration en packages, l'expérience est ce qui permet à chacun de décider quels sont les noms de nos forfaits.

    Sur les implémentations de l'emballage de vos interfaces dans le même emballage ou dans un autre il suffit de penser comment Java lui-même est structuré: généralement une classe d'implémentation sont emballés dans le même colis que son interface, mais n'est pas tout le temps.

    Si vous étiez sur le point d'avoir plusieurs implémentations de même de DAO alors il serait judicieux de les avoir structuré en .jdbc, .jpa ou .jdo sous-paquetages. Si vos n'en aura qu'une mise en œuvre à la fois des options de vous énumérer les sens, d'une certaine façon (même paquet ou un .impl sous emballage).

    Concernant les plus-ingénierie, je vous recommande cette l'article. Même si vous allez avoir juste une mise en œuvre de votre DAO, il serait judicieux de les avoir définis comme une interface et de l'application qui va vous aider dans un avenir possible de réécrire votre DAOs pour les autres cadres, tandis que le code qui permet de les utiliser maintient inchangé.

    À la fin, c'est à vous (ou vous et vos pairs) pour parvenir à un consensus et à prendre la décision qui fait plus de sens dans votre cas particulier.

    MODIFIER

    Une application a généralement une mise en œuvre par interface DAO et ce n'est pas un ingénieur, il n'a tout simplement pas de sens d'avoir la même interface DAO mis en œuvre pour JPA, et pour JDO. Certains des objectifs de l'utilisation de l'interface/modèle d'implémentation est de faciliter le re-factoring, les tests par des moyens de se moquer des objets, etc..

    P. S.: j'ai l'habitude de compter sur JDepend pour diffuser mes classes de l'application dans des emballages en évitant les cycles comme la plupart des que je peux.

    OriginalL'auteur Alonso Dominguez

  2. 2

    Je ne pense pas que ce soit est mieux, mais dans ce cas je préfère la première solution. Il serait en ligne avec le fait d'avoir ArrayList, LinkedList, etc. dans le même package que List.

    Lors de l'utilisation d'autres cadres, tels que hibernate je préfère la deuxième option avec MyDao et HibernateDao comme le réalisateur.

    OriginalL'auteur Johan Sjöberg

  3. 2

    Je voudrais aller avec votre deuxième option (même si aucun n'est vraiment mieux), parce que vous pouvez voir immédiatement dans votre importations si une impl est importé et de refactoring serait plus simple si vous souhaitez déplacer votre impl dans un autre projet.

    Ce n'est pas plus de génie. Il y a plusieurs avantages à utiliser DAO:

    1. Il améliore la qualité de votre code par le découplage de la base de données access à partir d'autres considérations
    2. De tester votre code est plus facile et vous pouvez le tester avec un grain plus fin.
    3. Si un jour, vous découvrez que Hibernate est vraiment beaucoup plus facile pour vous, il n'aura pas d'impact sur le reste de votre code.

    OriginalL'auteur Guillaume Polet

  4. 0

    Espaces de noms et les paquets ne sont là que pour éviter les collisions. Ni est préférable aussi longtemps qu'ils sont uniques.

    Donc c'est bon juste pour le nom de vos paquets de long, aléatoire chaînes de caractères? Sensible noms de package de le rendre plus facile pour les gens à naviguer dans votre API et peuvent faire du refactoring plus facile. Aussi, la séparation, par exemple, de la mise en œuvre et de l'interface est de bonne pratique dans les environnements où les exportations et les dépendances sont spécifiées par le paquet, comme vous allez, souvent, ne voulez dépendent soit de l'interface ou de la mise en œuvre.
    Ma réponse est spécifique à l'OP. Il n'y a pas de différence objective entre ses solutions de rechange proposées. En ce qui concerne votre commentaire, je ne peux que dire la création d'un langage compréhensible de l'espace de noms est de bon sens.

    OriginalL'auteur nsfyn55