Utilisation de DAO en tant que commande

Question

J'ai besoin d'un conseil à partir de l'une des approches de conception que nous considérons.

Nous implémentons un fournisseur de services Web Java qui agit sur les données dans une base de données relationnelle. Nos proposer des cours sont:

1. IDAO - interface avec méthode execute()
2. GetCustomerDAO et UpdateCustomerDAO implémente IDAO
3. DAOFactory - Liste des DAO pour être lit le fichier de configuration qui a une cartographie de OTI à être invoqués un service particulier.
4. ServiceImpl - contient les méthodes getCustomer, updateCustomer. Le service utilise DAOFactory pour obtenir la liste des objets DAO, puis itère sur la liste et appelle la méthode DAO.execute.

Je pense que c'est plus comme si nous avions converti des DAO en commande. Cependant, je n'aime pas assez cette approche pour certaines raisons: - Dans ServiceImpl: vous ne pouvez pas influencer le flux des DAO appelés. Par exemple après l'exécution de la première DAO si je ne veux pas exécuter la deuxième DAO mais exécuter la troisième DAO, il est difficile d'avoir ceci mis en application. - en outre ne sais pas si nous pouvons utiliser conceptuellement DAO. car un objet Command peut avoir une logique métier, mais les objets DAO ne doivent traiter que des aspects de lecture et d'écriture de données sur db.

S'il vous plaît laissez-moi savoir votre point de vue si le design semble approprié. merci

Answer 1

Je ne vois pas l'avantage d'utiliser le modèle de conception de commande dans ce cas.
1. L'idée avec DAO est de fournir une interface qui résume un mécanisme de persistance. Cette interface définit traditionnellement les méthodes CRUD. Chaque classe concrète DAO implémenterait typiquement l'interface DAO, pour un mécanisme de persistance spécifique. Par exemple, vous pourriez avoir une implémentation qui stocke des données dans une base de données relationnelle et une autre qui stocke des données dans un fichier xml. Ces deux implémentations peuvent être interchangeables puisqu'elles implémentent la même interface.
2. La fonctionnalité de service peut être séparée en une couche de service distincte. Normalement, cette couche dépend de votre couche DAO (pour la persistance). L'interface de service peut être similaire à une façade qui expose la logique métier implémentée dans l'application (généralement, la logique de la couche de gestion) à des clients potentiels. Exemple:
Interface utilisateur DAO:

 
public interface UserDao { 
    void save(User user); 
    void delete(User user); 
    void update(User user); 
    User findByUsername(String username); 
    List findAll(); 
    ... 
} 

Interface de service utilisateur:

 
public interface UserService { 
    void createUser(String username, String password); 
    boolean loginUser(String username, String password); 
    boolean isUsernameUnique(String username); 
    .... 
} 

mise en œuvre du service:

 
public class UserServiceImpl implements UserService { 

    private UserDao userDao; 

    public UserServiceImpl(UserDao userDao){ 
    this.userDao = userDao; 
    } 
    ... 
}