ЛС
Т.е. две сущности одна для доменного слоя другая для тайп орм
Size: a a a
2020 December 04
NM
но ведь то, что в доменной модели хранятся аннотации для ORM, уже нарушает SOLID) если уж так, можно сразу пойти в сторону entity schema
Нарушает, но даёт неоспоримый плюс в том, что я только в одном месте описываю данные
NM
Логинов Сергей
Т.е. две сущности одна для доменного слоя другая для тайп орм
Очень не хочется разносить описание данных на 2 класса(
Но даже если и так, пока не понял что мне это даёт? Ведь в сущности для ормки мне всё равно надо описать связи
Но даже если и так, пока не понял что мне это даёт? Ведь в сущности для ормки мне всё равно надо описать связи
ЛС
Орм связи для работы с бд
ЛС
А бизнес а доменный слой
ЛС
Конеш это та ещё жопа отделять фреймворк от бизнеса, как сделаешь расскажешь )
ЛС
А даёт это взять код бизнеса и перетащить в другой проект где другой фреймворк
ЛС
И оно должно работать
ЛС
И даже если там будет к примеру стиквалайз
ЛС
Или вообще сырые запросы
E
Очень не хочется разносить описание данных на 2 класса(
Но даже если и так, пока не понял что мне это даёт? Ведь в сущности для ормки мне всё равно надо описать связи
Но даже если и так, пока не понял что мне это даёт? Ведь в сущности для ормки мне всё равно надо описать связи
кроме того, ты избавишься от ограничений вроде технических полей для связей и паблик онли полей в моделях. на очень маленьком проекте это скорее всего не окупится
NM
И всё же, в случае конкретно моего кейса, когда мы не будем никуда переходить, а сущностей овердохера, и разносить их на 2 слоя не вариант, никак нельзя реализовать ManyToOne без OneToMany, как в доке написано?
ЛС
Ну ты же должен объеснить как релатион реализован
NM
Ну в sql я это описываю ссылкой какого-то поля из одной сущности на поле в другой
ЛС
Ну
NM
Почему в typeorm так сделать не получается для меня большой секрет
ЛС
И ты это делаешь в модели
ЛС
Entity
NM
Логинов Сергей
И ты это делаешь в модели
Ну в модели я вынужден делать связь в обе стороны зачем-то
NM
Хотя мне это не нужно