Наследование и REST API-контроллеры - работа с подклассами

Question

У меня есть следующая иерархия классов для разрабатываемой платформы купонов и сделок: *

Promotion - abstract
 - Coupon
 - Sale
 - Deal

( Купон , Продажа и Сделка Наследовать от Акции. Акция имеет строковый атрибут с именем type и абстрактный метод, который инициализирует атрибуты типа подклассов строковым значением. Например, type в купоне получает значение «Купон» и т.д ...)

Для каждого подкласса у меня есть DAO и Сервис классов, таких как CouponDAO, CouponService и т. Д.

В интерфейсных пользователях можно создать Купон или Продажа или Сделка через Угловой 2 интерфейс, поэтому я решил иметьследующие контроллеры:

PromotionController - abstract
 - CouponController
 - SaleController
 - DealController

( CouponController , SaleController , DealController наследуются от PromotionController )

PromotionController будет содержать все общие функции CRUD, общие для всех подклассов и в определенных контроллерахЯ буду обрабатывать конкретные операции, предназначенные для этих классов.

A) Проблема, с которой я сейчас сталкиваюсь, заключается в том, как создать экземпляр правильного объекта, поступающего со стороны клиента.Например, когда пользователь отправляет Купон или Продажа или Сделка , как создать экземпляр нужного объекта.Например, в PromotionController у меня есть такая функция ::

@RequestMapping(value=CREATE_PROMO, method=RequestMethod.POST)
    public ResponseEntity<?> create(@RequestBody Promotion promotion){
        promotionService.save(promotion);
        return new ResponseEntity<>("", HttpStatus.OK); 
    }

Promotion , которая является абстрактным аргументом функции.Нужно ли использовать фабричный шаблон и атрибут **type** для создания нужного объекта?Например, если type = "Coupon" , тогда я создаю объект Coupon, если это "Sale" , тогда я создаю объект Sale

B) Поскольку контроллериспользует объекты Services, это означает, что я должен объявить все три объекта служб в PromotionController .Потому что после создания экземпляра нужного объекта мне нужно вызвать соответствующий сервис для выполнения этой работы.В приведенном выше методе у меня есть PromotionService, который, я думаю, должен быть заменен правильным сервисом подкласса

C) Я ищу, как обращаться с API REST, который работает с подклассами в реальном мире, как ситуация, которую я описалвыше

D) Я думал об упрощении для себя путем копирования всех операций CRUD на их конкретные контроллеры, но, похоже, это будет повторяющийся код.

Я думаю, что есть лучший способ сделать это.

Я также пытался найти проект с открытым исходным кодом, который имеет дело с этими ситуациями, но, кажется, все проекты, которые я нашел, используютодин класс а не наследство.Их REST / API не обрабатывают ситуации наследования

Answer 1

На мой взгляд, держите ваши конечные точки простыми.С точки зрения REST API создайте отдельный или только один контроллер и используйте следующие шаблоны после уровня контроллера.Из того, что я видел, всегда лучше держать конечные точки REST подальше от наследования / повторного использования и применять их позже после получения и проверки запросов.

Чтобы создать экземпляр уровня обслуживания / помощника из контроллеров, используйте шаблон фабричного метода:

https://en.wikipedia.org/wiki/Factory_method_pattern

Создайте PromotionServiceFactory, который возвращает реализацию PromotionService в зависимости от типа продвижения.

В контроллере вызовите соответствующий метод сервиса продвижения, используя фабрику.Фабрики по-прежнему принимают аргументы типа Promotion.

@RequestMapping(value=CREATE_COUPON, method=RequestMethod.POST)
    public ResponseEntity<?> create(@RequestBody Promotion promotion){
//helper if adding one more helper layer. The factory invocation is then //transferred to the helper layer
  PromotionService couponService = promotionServiceFactory.get(PROMOTYPES.COUPON);
couponService.save(promotion);
        return new ResponseEntity<>("", HttpStatus.OK); 
    }

Судя по вашим вопросам, существуют общие CRUD / другие методы для разных типов продвижения.Это хороший кандидат на шаблон шаблона в слое обслуживания, если некоторые этапы / подзадачи одинаковы для каждого продвижения, а другие различаются.В противном случае вы можете просто сохранить общие методы CRUD, создав службу абстрактного продвижения.

https://en.wikipedia.org/wiki/Template_method_pattern

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

Answer 2

чтобы ответить вам (A), я думаю, вы могли бы использовать метод requestObject.instanceOf (), чтобы указать правильный тип подкласса, а затем обработать с правильным обработчиком.

Answer 3

Я думаю, вы можете справиться с этим двумя способами в зависимости от логики.Если вы хотите сохранить все отдельно, создайте разницу конечных точек для купона / сделки / продажи.Таким образом, каждая конечная точка будет вызывать свой контроллер и т. Д.

2) Если вы думаете, что код тот же, то вы можете использовать абстрактный шаблон фабрики для создания экземпляра правильного сервиса и объекта DAO.

Все этоВ зависимости от требований вашего бизнеса, я бы предпочел второй способ, если логика кода почти одинакова.Один контроллер на наследование, поэтому в будущем при увеличении иерархии вам не нужно создавать несколько классов, пока не потребуется.