компоненты или бизнес сервисы модуля, соблюдая инверсию зависимостей? Вот пример абстракции стейт менеджера. Пытаюсь разобраться, где архитектурно правильно ее хранить. https://github.com/evoytenkoapps/angular-best-practices/blob/master/examples/src/app/redux-store-ngxs/_services/facade/facade/animal.facade.ts
Думаю ближе к самому классу/коду который хотите спрятать в фасаде
соблюдая dip, нужно наоборот, нужно хранить ближе к тому кто "выше" чем стора
И кто выше тогда?
ну точно выше сервис с бизнес логикой. но у меня все логика в компоненте, и в моем случае, наверное компонент выше сторы.
Я вот думаю нужно ли для "фасад" класса делать отдельный класс? Почему бы сервису не быть фасадом?
Видел где-то на просторах интернета, что делали обычный сервис, и к нему еще фасад
сервис вместо state manager?
А если ты делаешь либу в которой ты експортишь стор. Не будешь создавать фасад где ближе, а наверное в самой либе
Я бы в корень фича модуля положил интерфейс/абстрактный класс, а в папке со стором - сделал реализацию фасада
Во! тоесть примерно так? ./feature feature.module.ts feature.facade.ts ?
А как решать проблему когда стор надо перенести в либу и шарить между апками, как получить доступ к интерфейсу который в фиче?
Кстати, если упарываться по solid, то надо еще interface segregation. Т.е. разделить интерфейс фасада на несколько и потом в фасаде реализовать их все. Но в Ангуляре слишком бойлерплейтно будет, т.к. нельзя по интерфейсам инжектить
что за интерфейс?
это если в фасаде будет куча методов? например больше 10 ?
так по идее импорт и решит эту проблему.
Это если в либе хранить все что связано с фичей
Я думаю, выделять стор в отдельную либу - не очень хорошая идея, лучше делить по фичам
у меня сейчас так, но вот недавно задался вопросом, что будет если вынести фичу в лейзи. как реализация сторы загрузится в стейт менеджер из лейзи, у меня сейчас возможно отключен лейзи, поэтому проблем нет. не подскажите из вашего опыта?
Нормально работает, так и делаем, фича-стор в лейзи лежит
а у вас какой стейт менеджер или менеджеры?
Тут дело не в количестве методов, а в количестве потребителей, т.е. по сути, компонентов. Если есть несколько независимых друг от друга модулей с компонентами, которые юзают один фасад - то можно каждому сделать свой интерфейс
правильно я понимаю, что в этом случае, с точки зрения компонента, мы соблюдаем SRP. А с точки зрения фасада, зачем так делать? Не проще сделать N фасадов, под каждый компонент?
Можно и так. Но, в принципе, реализация может быть одна, это не имеет значения. Важно, что интерфейсы поделены
Обсуждают сегодня