Лучшая практика обработки доменных объектов Spring MVC

Question

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

Где вы «конвертируете» идентификатор объекта домена в объект домена, загружая его из базы данных?Контролер не должен этого делать.Таким образом, интерфейс метода службы должен использовать Accept ИДЕНТИФИКАТОР принадлежащий объект домена вместо самого объекта домена.Но интерфейс сервиса был бы лучше, если бы он принимал объект домена в качестве параметра.

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

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 это может быть точкой отключения для локальных служб).