Spring MVC Domaine objet de manipulation des meilleures pratiques

Question

Supposons aussi 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ù avez-vous « convertir » l'ID de l'objet de domaine dans l'objet de domaine en le chargeant de la base de données? Cela ne devrait pas être fait par le contrôleur. Ainsi, l'interface de méthode de service doit utiliser accepter le ID objet de domaine au lieu de l'objet lui-même domaine. Mais l'interface du service serait plus agréable si elle prend l'objet de domaine en tant que paramètre.

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

Answer 1

Le contrôleur doit passer l'id vers le bas dans la couche de service, puis récupérer tout ce qui est nécessaire pour rendre le reste de la réponse HTTP.

-

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. Le but entier de la couche de service est d'obtenir des objets de domaine et leur dire d'effectuer leur logique métier. Ainsi, un appel de base de données doit 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 de mes projets je 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 les ID si possible à des services distants mais 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 pour les services à distance et empêche plusieurs appels à OTI pour les services locaux (bien que Hibernate en cache ce pourrait être un point muet pour les services locaux).