Практика обработки доменных имен Spring MVC Best Practice

Question

Предполагается использовать простой Spring MVC Controller, который получает идентификатор объекта домена. Контроллер должен вызвать службу, которая должна что-то сделать с этим объектом домена.

Где вы «конвертируете» идентификатор объекта домена в объект домена, загружая его из базы данных? Контроллер не должен выполнять это. Таким образом, интерфейс метода службы должен использовать команду ID объекта домена вместо самого объекта домена. Но интерфейс службы будет приятнее, если объект домена станет параметром.

Что вы думаете об этом распространенном случае? Как вы это решаете?

Answer 1

Контроллер должен передать идентификатор в сервисный уровень, а затем вернуть все необходимое, чтобы отобразить остальную часть ответа HTTP.

Так -

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

Все остальное просто будет загрязнять веб-слой, который не должен заботиться вообще о настойчивости. Вся цель уровня сервиса - получить объекты домена и сказать им, чтобы они выполнили свою бизнес-логику. Таким образом, вызов базы данных должен находиться на служебном уровне как таковой -

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

Answer 2

в проекте шахты я использовал слой службы:

class ProductService { 

    void removeById(long id); 

} 

Answer 3

Я думаю, что это будет зависеть от того, услуга удаленного или локального. Как правило, я пытаюсь передать идентификаторы, где возможно, удаленным службам, но предпочитаю объекты для локальных.

Причиной этого является то, что он снижает сетевой трафик, отправляя только то, что абсолютно необходимо для удаленных служб, и предотвращает множественные вызовы DAO для локальных служб (хотя с кэшированием Hibernate это может быть непринужденной точкой для локальных служб).