Согласен с тем, что пример из статьи быстрее и проще реализовать через шаблоны в IDE.
Данный пример был сделан для упрощения понимания кодогенерации, чтобы показать, что это не сложно.
У нас в организации используются более сложные кодогенераторы, которые через IDE шаблоны было бы сделать проблематично.
Добрый день! Да, у нас так же используются более сложные генераторы, чем описанный в статье.
Хотелось упростить пример, сократить логику, чтобы показать как работать с кодогенерацией на простом примере.
В проекте команды несколько различных подходов построения запросов, ODATA, RQL, QueryBuilder. GORM позволяет загружать/сохранять из репозиториев целый агрегат, включая связные сущности. Это удобно при использовании подхода DDD и работе через агрегаты. В случае запросов чтения используем отдельную модель для чтения, там уже либо GORM, либо что-то другое, какой команде как удобно.
Последовательно – долго бывает, когда 3-5 запросов
Новый хендлер на бекенде – проблему решает, но ухудшает архитектуру бекенда
GraphQL – да, я тоже смотрел в сторону этого решения… но там тоже есть свои проблемы для бекенда, оптимизация запросов со связями, например
HTTP2 не пробовали? Мне кажется, оно бы помогло решить проблему скорости последовательных запросов
Хотелось бы узнать, как решали проблемы, когда нужно было получить информацию о сущностях по REST, зависящую друг от друга (нельзя получить параллельно). Совмещали все в одном запросе?
С вашим мнением по поводу знания чистого JavaScript я согласен. Был несогласен лишь с тем кодом, написали бы хоть, что это антишаблон, а то… статья для ведь для начинающих. JavaScript пока что вообще стал моим любимым языком, я полюбил прототипы.
Данный пример был сделан для упрощения понимания кодогенерации, чтобы показать, что это не сложно.
У нас в организации используются более сложные кодогенераторы, которые через IDE шаблоны было бы сделать проблематично.
Хотелось упростить пример, сократить логику, чтобы показать как работать с кодогенерацией на простом примере.
В проекте команды несколько различных подходов построения запросов, ODATA, RQL, QueryBuilder. GORM позволяет загружать/сохранять из репозиториев целый агрегат, включая связные сущности. Это удобно при использовании подхода DDD и работе через агрегаты. В случае запросов чтения используем отдельную модель для чтения, там уже либо GORM, либо что-то другое, какой команде как удобно.
Новый хендлер на бекенде – проблему решает, но ухудшает архитектуру бекенда
GraphQL – да, я тоже смотрел в сторону этого решения… но там тоже есть свои проблемы для бекенда, оптимизация запросов со связями, например
HTTP2 не пробовали? Мне кажется, оно бы помогло решить проблему скорости последовательных запросов
то, в app\controllers
ладно) думаю, что на следующей неделе потестирую вашу панель
javascript.ru/tutorial/dom/attributes
не будет работать в младших версиях IE — там использовался ActiveX.