А что он нормально написал, налил воды и наныл, что чаще выбирают реакт, чем другие решения. Только мне непонятно, какую проблему пытается решить автор. Тут даже зацепиться за что-то нельзя, так как тезисов нет по сути, просто вода. Какую проблему поднимает автор и как он предлагает ее решить - непонятно. Не вижу ни одной причины для себя после прочтения статьи резко задуматься о том, что нужно начать читать доки svelte
А когда проект будет на пару сотен тысяч строк кода, тоже фреймворк не нужен? Под каждую задачу нужен свой инструмент, пилить лендинг на фреймворке вряд ли целесообразно. С другой стороны реакт это библиотека, которая инкапсулирует работу с домом. Если использовать ее по прямому назначению то, удивительно, но все становится не так уж и плохо
А разве все это не решается интерсептором для парсинга ответа и выкидыванием ошибки определенного класса Clietn/Server error. Обычно над голым фетчом есть какой то апи клиент, где все это реализуется, в том числе ретраи и прочее. Хотя если задача библиотеки написать свой аксиос на базе фетча, наверное это имеет смысл
В целом я понял подход, отчасти у меня он похож, но много работы с редактированием лежит на клиенте. С бэком происходит переодическая синхронизация, для обновления данных. Дто являются основой для создание моделей (в вашем примере, если я верно понял - это репозитории). Модели составляют собой коллекции. Есть ViewModel - связка компонента с моделями, ViewModel обычно связаны с кокнретным компонентом, но могут быть более абстрактными и досступными через DI в некскольких местах приложения. Аналог UseCase в моем случае служат оркестраторы, но отличие только в нейминге. ViewModel также может менять модели в обход UseCase если это тупой сеттер. Но вот меня в последнее время это стало напрягать, что если теперь поле модели не просто сеттер, а какой-то UseCase, и теперь мы не просто должны дергать toggleChecked, а должны всегда действовать в рамках определенной бизнес логики, как бить по рукам тем, кто пытается обойти эту бизнес логику.
У меня был кейс, где изменение одной модели, должно было влиять на другую модель, при этом они были не связаны отношением агрегации, а были независимы друг от друга в иерархии доменных сущностей. Я решил эту проблему через медиаторы. Но решение мне не очень нравится, особенно если потребуется задействовать какие-то сервисы в ходе процесса изменения, прокидывать сервисы в модели или создавать между моделями прямые связи вообще не хочется, по хорошему нужно вынести это в UseCase, но тогда я не смогу гарантировать, что бизнес логика всегда соблюдается, а гарантировать это хочется на уровне кода, хотя возможно я упоролся)
А почему решили использовать иммутабельный подход и самописный DI? Как я понимаю захотели ограничения на уровне DI в инъектировании сервисов или были еще причины? Я взял mobx + typedi++ (наследник typedi).
Попробую еще раз, у меня на самом деле тупорылый вопрос :)
Как вы организуете код так, чтобы не было бойлерплейта при этом изменения моделей проходило через заданные точки входа (useCases в вашем примере, если я верно понял), если у модели 100500 полей, то придется их поддерживать и в точках входа, а если позволить обходить точку входа для изменения модели, то как гарантировать, что модель меняется корректно там где ее нужно менять через точку входа.
Например я хочу поменять поле name модели user, я иду в сервис и вызываю userService.setValue(readonlyUser, "name", "newName") передаю в него райт онли модель или ее айди и новое значение, у моделей может быть много "тупых" сеттеров, которые просто меняют поле на переданное значение, если мы организуем все через единые точки входа, то придется поддерживать согласованность точки входа и модели. Если мы хотим избежать бойлерплейта и позволяем коду приложения вызывать тупые сеттеры моделей напрямую, user.name = "newName" или user.setName("newName"), то как гарантировать, что те значения, изменять которые можно только через useCase, будут изменены через них, и в код не просочится аналог user.name = "newValue", когда это поле можно изменить только так userService.setValue(readonlyUser, "name", "newName"). У меня есть несколько мыслей на этот счет, но вполне возможно что я либо оверхедом занимаюсь, либо есть решения эллегантнее, хотелось бы узнать ваш подход.
Я понимаю под моделью какую-то бизнес сущность, минимальный юнит бизнес логики, ее основа, с тем с чем работает в итоге бизнес логика, единый источник правды, также для поддержки модели могут создаваться промежуточные модели, которые связывают несколько моделей вместе или изолируют часть модели в отдельную, с которой можно работать независимо от основной
А гарантии того, что разработчик не начнет менять модель в обход useCase есть какие-то на уровне кода, статической типизации или ограничения доступа к получению моделей? Или только на уровне соглашений между разработчиками?
пример из проекта, мне прилетает огромная древовидное dto, где поля ассоциируются с разными бизнес сущностями, часть из которых независима друг от друга, часть агрегирована и тд. На основе этой дто происходит создание моделей, которые сохраняют структуру заданную в dto, если они связаны друг с другом. У всех этих моделей очень много полей, которые можно изменять. Как в вашем подходе должны происходить такие изменения, то есть есть модель, у нее есть поле имя, описание и тд. Мы можем изменять эти данные, и эти изменения не требуют какой-то бизнес логики, буквально примитивный сеттер. Вы для их изменения заводите свои/свой useCase или позволяете менять такие данные напрямую, минуя useCase? Появляется ли бойлерплейт, когда нужно по сути дублировать эти сеттеры в отдельном useCase?
Представим что есть какие то дто которые бэк присылает на клиента, эти дто становятся основой для моделей. У моделей есть свои методы и поля. Есть слой вью модели, который связывает наше вью с моделью и изменяется модель через этот слой, предположим появилось бизнес правило, после изменение каких-то данных в модели, обновлять данные в другой доменной модели. Это бизнес правило должно соблюдаться всегда. Чтобы не дублировать его между разными вью моделями мы выносим эту логику в какой-то сервис и теперь, чтобы изменить поле модели, необходимо вызвать соответствующий метод сервиса. Как вы обеспечиваете гарантию того, что кто-то из разработчиков не нарушит эту логику и не получит доступ к модели напрямую в каком-то другом сервисе или вью модели и не изменит ее обойдя бизнес правило? Есть ли какая-то изоляция моделей, когда ты не можешь получить к ним доступ обойдя бизнес правила?
Интересен такой момент, как работаете с доменными моделями, позволяете ли их читать, писать в них напрямую или нет, если нет, то как гарантируется соблюдение бизнес логики, когда например для изменения модели необходимо делать это через сервис, потому что он дополнительно агрегирует в себе информацию, которая нужна для изменения модели? Я имею в виду защиту от того, что кто-то решит изменять модель в обход бизнес логики. Также интересует вопрос о том, как организовано взаимодействие моделей между друг другом, если оно необходимо, когда изменения данных одной модели влияет на данные другой, при этом эти модели относятся к разным доменным сущеостям
Архитектура это про связь и взамодействие сущностей между собой. Производной от этого может быть файловая структура, а может и не быть. Расположение файла не должно влиять на архитектуру. Если я извращенец, могу хранить все в одной директории src и жить спокойно, это не должно ломать существующую архитектуру. Примерами архитектуры являются MV* паттерны и их модификации.
В npm "mobx-tanstack-query". Поэтому я и указал про этот пакет, чтобы самим не изобретать велосипед. По сути тот же ReactQuery/TanstackQuery только не прибитый к реакту
в моей курсовой было меньше воды)
Вы только это публично не говорите, пойду покликаю формошлепную фигму
У вас есть доки апи, ну как у других, заходишь, нажимаешь апи и там список классов, функций и т.д. с описанием что это и для чего?
Адепты двух религий уже в комментах. Их библиотеки объединяет лишь одна вещь, ими никто не пользуется
По жалобам на мемоизацию и коллбэки можно предположить, что автор никогда и не пробовал писать нормально, максимум редакс
Mobx или любую другую библиотеку для реактивности вместо реактовского кор стейта я как понимаю запрещает использовать какая-то религия?
А что он нормально написал, налил воды и наныл, что чаще выбирают реакт, чем другие решения. Только мне непонятно, какую проблему пытается решить автор. Тут даже зацепиться за что-то нельзя, так как тезисов нет по сути, просто вода. Какую проблему поднимает автор и как он предлагает ее решить - непонятно. Не вижу ни одной причины для себя после прочтения статьи резко задуматься о том, что нужно начать читать доки svelte
А когда проект будет на пару сотен тысяч строк кода, тоже фреймворк не нужен? Под каждую задачу нужен свой инструмент, пилить лендинг на фреймворке вряд ли целесообразно. С другой стороны реакт это библиотека, которая инкапсулирует работу с домом. Если использовать ее по прямому назначению то, удивительно, но все становится не так уж и плохо
Тут нет одного самого сильнейшего фреймворка
Нельзя произносить это название вслух
А разве все это не решается интерсептором для парсинга ответа и выкидыванием ошибки определенного класса Clietn/Server error. Обычно над голым фетчом есть какой то апи клиент, где все это реализуется, в том числе ретраи и прочее. Хотя если задача библиотеки написать свой аксиос на базе фетча, наверное это имеет смысл
В целом я понял подход, отчасти у меня он похож, но много работы с редактированием лежит на клиенте. С бэком происходит переодическая синхронизация, для обновления данных. Дто являются основой для создание моделей (в вашем примере, если я верно понял - это репозитории). Модели составляют собой коллекции. Есть ViewModel - связка компонента с моделями, ViewModel обычно связаны с кокнретным компонентом, но могут быть более абстрактными и досступными через DI в некскольких местах приложения. Аналог UseCase в моем случае служат оркестраторы, но отличие только в нейминге. ViewModel также может менять модели в обход UseCase если это тупой сеттер. Но вот меня в последнее время это стало напрягать, что если теперь поле модели не просто сеттер, а какой-то UseCase, и теперь мы не просто должны дергать toggleChecked, а должны всегда действовать в рамках определенной бизнес логики, как бить по рукам тем, кто пытается обойти эту бизнес логику.
У меня был кейс, где изменение одной модели, должно было влиять на другую модель, при этом они были не связаны отношением агрегации, а были независимы друг от друга в иерархии доменных сущностей. Я решил эту проблему через медиаторы. Но решение мне не очень нравится, особенно если потребуется задействовать какие-то сервисы в ходе процесса изменения, прокидывать сервисы в модели или создавать между моделями прямые связи вообще не хочется, по хорошему нужно вынести это в UseCase, но тогда я не смогу гарантировать, что бизнес логика всегда соблюдается, а гарантировать это хочется на уровне кода, хотя возможно я упоролся)
А почему решили использовать иммутабельный подход и самописный DI? Как я понимаю захотели ограничения на уровне DI в инъектировании сервисов или были еще причины? Я взял mobx + typedi++ (наследник typedi).
Попробую еще раз, у меня на самом деле тупорылый вопрос :)
Как вы организуете код так, чтобы не было бойлерплейта при этом изменения моделей проходило через заданные точки входа (useCases в вашем примере, если я верно понял), если у модели 100500 полей, то придется их поддерживать и в точках входа, а если позволить обходить точку входа для изменения модели, то как гарантировать, что модель меняется корректно там где ее нужно менять через точку входа.
Например я хочу поменять поле name модели user, я иду в сервис и вызываю userService.setValue(readonlyUser, "name", "newName") передаю в него райт онли модель или ее айди и новое значение, у моделей может быть много "тупых" сеттеров, которые просто меняют поле на переданное значение, если мы организуем все через единые точки входа, то придется поддерживать согласованность точки входа и модели. Если мы хотим избежать бойлерплейта и позволяем коду приложения вызывать тупые сеттеры моделей напрямую, user.name = "newName" или user.setName("newName"), то как гарантировать, что те значения, изменять которые можно только через useCase, будут изменены через них, и в код не просочится аналог user.name = "newValue", когда это поле можно изменить только так userService.setValue(readonlyUser, "name", "newName"). У меня есть несколько мыслей на этот счет, но вполне возможно что я либо оверхедом занимаюсь, либо есть решения эллегантнее, хотелось бы узнать ваш подход.
Я понимаю под моделью какую-то бизнес сущность, минимальный юнит бизнес логики, ее основа, с тем с чем работает в итоге бизнес логика, единый источник правды, также для поддержки модели могут создаваться промежуточные модели, которые связывают несколько моделей вместе или изолируют часть модели в отдельную, с которой можно работать независимо от основной
А гарантии того, что разработчик не начнет менять модель в обход useCase есть какие-то на уровне кода, статической типизации или ограничения доступа к получению моделей? Или только на уровне соглашений между разработчиками?
пример из проекта, мне прилетает огромная древовидное dto, где поля ассоциируются с разными бизнес сущностями, часть из которых независима друг от друга, часть агрегирована и тд. На основе этой дто происходит создание моделей, которые сохраняют структуру заданную в dto, если они связаны друг с другом. У всех этих моделей очень много полей, которые можно изменять. Как в вашем подходе должны происходить такие изменения, то есть есть модель, у нее есть поле имя, описание и тд. Мы можем изменять эти данные, и эти изменения не требуют какой-то бизнес логики, буквально примитивный сеттер. Вы для их изменения заводите свои/свой useCase или позволяете менять такие данные напрямую, минуя useCase? Появляется ли бойлерплейт, когда нужно по сути дублировать эти сеттеры в отдельном useCase?
Представим что есть какие то дто которые бэк присылает на клиента, эти дто становятся основой для моделей. У моделей есть свои методы и поля. Есть слой вью модели, который связывает наше вью с моделью и изменяется модель через этот слой, предположим появилось бизнес правило, после изменение каких-то данных в модели, обновлять данные в другой доменной модели. Это бизнес правило должно соблюдаться всегда. Чтобы не дублировать его между разными вью моделями мы выносим эту логику в какой-то сервис и теперь, чтобы изменить поле модели, необходимо вызвать соответствующий метод сервиса. Как вы обеспечиваете гарантию того, что кто-то из разработчиков не нарушит эту логику и не получит доступ к модели напрямую в каком-то другом сервисе или вью модели и не изменит ее обойдя бизнес правило? Есть ли какая-то изоляция моделей, когда ты не можешь получить к ним доступ обойдя бизнес правила?
Интересен такой момент, как работаете с доменными моделями, позволяете ли их читать, писать в них напрямую или нет, если нет, то как гарантируется соблюдение бизнес логики, когда например для изменения модели необходимо делать это через сервис, потому что он дополнительно агрегирует в себе информацию, которая нужна для изменения модели? Я имею в виду защиту от того, что кто-то решит изменять модель в обход бизнес логики. Также интересует вопрос о том, как организовано взаимодействие моделей между друг другом, если оно необходимо, когда изменения данных одной модели влияет на данные другой, при этом эти модели относятся к разным доменным сущеостям
https://habr.com/ru/articles/934698/comments/#comment_28689542
Архитектура это про связь и взамодействие сущностей между собой. Производной от этого может быть файловая структура, а может и не быть. Расположение файла не должно влиять на архитектуру. Если я извращенец, могу хранить все в одной директории src и жить спокойно, это не должно ломать существующую архитектуру. Примерами архитектуры являются MV* паттерны и их модификации.
В npm "mobx-tanstack-query". Поэтому я и указал про этот пакет, чтобы самим не изобретать велосипед. По сути тот же ReactQuery/TanstackQuery только не прибитый к реакту