Spring MVC Domain Gestion des objets Meilleures pratiques

Question

Supposons un simple contrôleur Spring MVC qui reçoit l'ID d'un objet de domaine. Le contrôleur doit appeler un service qui devrait faire quelque chose avec cet objet de domaine. Où est-ce que vous "convertissez" l'ID de l'objet de domaine dans l'objet de domaine en le chargeant à partir de la base de données? Cela ne devrait pas être fait par le contrôleur. L'interface de méthode de service doit donc accepter l'ID de l'objet de domaine au lieu de l'objet de domaine lui-même. Mais l'interface du service serait plus agréable si elle prenait l'objet domaine en paramètre.

Que pensez-vous de ce cas d'utilisation courant? Comment résolvez-vous cela?

Answer 1

Le contrôleur doit transmettre l'ID dans la couche de service, puis récupérer tout ce qui est nécessaire pour restituer le reste de la réponse HTTP.

Alors -

Map<String,Object> doGet (@RequestParam("id") int id) { 
    return serviceLayer.getStuffByDomainObjectId(id); 
} 

Tout le reste va tout simplement polluer la couche Web, qui ne devrait pas prendre soin du tout de la persistance. L'objectif entier de la couche de service est d'obtenir des objets de domaine et de leur dire d'exécuter leur logique métier. Ainsi, un appel de base de données devrait résider dans la couche de service en tant que telle -

public Map<String,Object> getStuffByDomainObjectId(int id) { 
    DomainObject domainObject = dao.getDomainObjectById(id); 
    domainObject.businessLogicMethod(); 
    return domainObject.map(); 
} 

Answer 2

dans un projet de la mine, j'utilise la couche de service:

class ProductService { 

    void removeById(long id); 

} 

Answer 3

Je pense que cela dépendrait si le service est distant ou local. En règle générale, j'essaie de transmettre des ID lorsque cela est possible aux services distants, mais je préfère les objets pour les locaux. Le raisonnement derrière cela est qu'il réduit le trafic réseau en envoyant uniquement ce qui est absolument nécessaire aux services distants et empêche plusieurs appels aux DAO pour les services locaux (bien que la mise en cache Hibernate soit un point muet pour les services locaux).