Rethinking purposes of Storage classes

[KostyaZgara]

Я думаю, что сейчас в storage классах находится какая-то часть бизнес логики, даже вижу, что там сам userService юзается, хотя должно быть наоборот. UserService должен управлять Storage, а сам Storage должен быть очень глупых, вплоть до того что прям абстрактным.

Например, может быть дефолтный Storage для ресурсов:

abstract class AbstractStorage<T> {
  protected _data: T[];
  public retrieve(id: string): Promise<T> {
    // find resource by id
  }
  public delete(id: string): Promise<void> {
    // delete resource by id
  }
  // etc
}

И потом наследовать и расширять этот клас с уже частью реализованного функционала

class UserStorage extends AbstractStorage<User> {
  public someSpecificMethod(idUser: string) {}
}

const userStorage = new UserService();
userStorage.retrieve('id-user'); // we have already implemented retrieve method
userStorage.someSpecificMethod(); // expanded default functionality

И так, на всякий случай. Ты хотел этого или нет, но неявно реализовал паттерн Repository :) Поэтому лучше сделать его явным и использовать Repository вместо Storage

[vadim-tarasenko]

Мені здається що бізнес логіка (запити до апі, алгоритми обрахунків ...) має лежати в сервісах. А в Storage буде логіка, яка викликатиметься із самого ui і буде управляти лише стором.