Архитектура CRUD - приложения.

 
 
 
Сообщения:3
Всем доброго дня. Прошу высказать мысли по поводу архитектуры небольшого CRUD - приложения.

Есть некая ентити, вокруг которой, собственно, крутится все приложение (Spring Boot Data JPA). Общение с клиентом - REST.
У сущности есть несколько параметров, например - длина, толщина, дата производства, серийник, etc. На основе некоторых из них заполняются выпадающие списки на клиенте при создании нового экземпляра для сохранения. В будущем список параметров однозначно немного подрастет. Плюсом к этому, по плану, админ может с вебморды редактировать эти параметры (у каждого свой crud :D ).

Вопрос номер раз: на каждый из таких параметров необходимо создавать "свою" сущность для сохранения в БД, попутно репозиторий и сервис?
Или же можно сделать один сервис на дженериках для однотипных параметров? Ведь у некоторых, по сути, из полей только id и, собственно, параметр. Если да, то как туда инжектить определенный репозиторий?

Вопрос номер два: рест контроллер должен делегировать все действия юзера куда-то в мэин-логику. Как это организовать? Создать какой-то класс, в который проинжектить ВСЕ сервисы и в нем создавать кучу методов по работе с ними? Опять же, где определить классы DTO для отправки на клиент "чистых" данных, чтобы не разбирать сущности на клиенте для отображения (это что касается именно параметров).

Вопрос номер три: допустим, с клиента прилетает запрос на удаление параметра, содержащий какой-то алиас этого параметра и его айди. Как обыграть эту ситуацию? В первой редакции было что-то типа
swich (alias){
   case "t": repo = typeRepo;
   break;
   case "c": repo = cordLenRepo;
   break;
  // ...
}

repo.delete(id);
//...

Но это же фу!

Ну и в заключение (а то и так многабукоф).
Может я в корне неправильно организовал все приложение, подскажите, хотя бы в общих чертах, грамотное решение.
Еще раз, вкратце: организовать crud для сущности с параметрами, для каждого из который - свой crud.

Заранее спасибо всем откликнувшимся, извините за сумбурность!
 
 
Сообщения:9785
iSmoke:
архитектуры небольшого CRUD приложения.
Это какие-то несовместимые вещи. CRUD - это 4 очень простых действия, тут сложно что-то архитектурить.
iSmoke:
У сущности есть несколько параметров, например - длина, толщина, дата производства, серийник, etc. На основе некоторых из них заполняются выпадающие списки на клиенте при создании нового экземпляра для сохранения. В будущем список параметров однозначно немного подрастет.
Т.е. есть у сущности поля, причем значения этих полей ограничено словарями?

Словари можно делать двумя способами:
1. Либо сохранять само значение. Т.е. COUNTRY=Belgia
2. Либо ссылаться на значение из словаря. Т.е. в основной сущности хранить ID значения, например, COUNTRY_ID=1

В первом случае все просто - одна таблица типа ключ-значение на все словари, значения можно хоть через запятую хранить:
COUNTRIES=Belgia,Russia,Ukraine, ..
PLANETS=Venus,Mercuri,Earth

Во-втором случае либо оставляем одну таблицу:
COUNTRY=Belgia
COUNTRY=Russia
COUNTRY=Ukraine
PLANET=Venus
...

Либо все же на каждый словарь по таблице (COUNTRIES, PLANETS, etc).

В итоге во всех случаях кроме последнего нужен один Endpoint и один Repository объект. В последнем на каждый словарь нужно по Endpoint'у, по таблице и по Repository. Если запрос на добавление какого-то значения в словарь пришел, то он пришел в определенный endpoint, соответственно тот вызовет определенный Repository без каких-либо условий.
Изменен:02 фев 2019 10:01
 
 
Сообщения:3
Спасибо за ответ!

Староверъ:
Т.е. есть у сущности поля, причем значения этих полей ограничено словарями?

Именно так
Староверъ:
Т.е. в основной сущности хранить ID значения, например, COUNTRY_ID=1

На данный момент так и есть
Староверъ:
на каждый словарь нужно по Endpoint'у

Т.е. на действие с каждым словарем в контроллере свой метод, я правильно понял?
 
 
Сообщения:9785
Ага
 
Модераторы:Нет
Сейчас эту тему просматривают:Нет