Вот, саму верстку форм вроде обсудили. Лучшее к чему пришло человечество можно назвать: декларативный UI с функциональной интеграцией.
Это все самые передовые фрейморки — такие как Flutter, Jetpack Compose, SwiftUI, React. Т.е. все самое передовое и современное — авангард вертски можно сказать. Чистый декларативный дедовский подход не удобен и существует только как легаси.
Что же касается управления этим UI — то что все-таки лучше на ваш взгляд?
Подход
Часто используется в
MVC
ASP.NET, Django, Ruby on Rails
MVP
Android (раньше), WinForms
MVVM
WPF, Xamarin, Flutter
Redux / UDF
React, Angular, Flutter
BLoC
Flutter
Elm / TEA
Elm, Flutter
Clean Architecture
Любые масштабируемые проекты
Вот, поработал с BLoC. Вроде норм, но даже банальный диалог для подтверждения действия — как бы уже добавляет лишней работы. Т.е. прямо в логике (в bloc диалог вызвать нельзя), значит нужно добавить доп. состояние — требуется отобразить диалог, потом событие от диалога, потом обработку события и т.д. Как бы нет той простоты — когда 1 строчкой отобразил диалог и дальше продолжил выполнять код
Правильнее будет — паттерны управления состоянием. state management — устоявшийся термин, что гораздо правильнее т.к. UI это малая часть того чем надо управлять.
S>
S>
S>
Подход
S>
Часто используется в
S>
S>
S>
MVC
S>
ASP.NET, Django, Ruby on Rails
S>
S>
MVC это совсем необязательно серверное решение. Автономный клиент безо всякого сервера точно так же может быть на MVC
В этом случае код получает довольно близким к разновидностям redux:
вместо reducer будет command
вместо enhancer будет плагин или мидлвара
вместо мидлвары будет или команда или команда-мидлвара или тоже мидлвара
модель может быть пассивной, активной, реактивной, мутабельной, иммутабельно, какой угодно, в отличие от редукс модель только иммутабельная пассивная.
например.
mvc
conroller.execute(Action.DocumentOpen)
контроллер находит команду-обработчик,
вызывает её с учетом всех нужных мидлвар итд, передает модель как аргумент
команда обновляет состояние модели
в конце контроллер вызывает обновление UI
— метод update у каждого из view
— event update на который подписаны все view
— observable/subscription на который подписаны все view
— кидает в шину сообщение update
последние два варианта наиболее близки к redux
redux
store.dispatch(Action.DocumentOpen)
store вызывает все редюсеры
потом вызывает мидлвару
сохраняет новое состояние модели
триггерит subscription на который подписаны все view
Здравствуйте, Shmj, Вы писали:
S>Вот, саму верстку форм вроде обсудили. Лучшее к чему пришло человечество можно назвать: декларативный UI с функциональной интеграцией.
S>Это все самые передовые фрейморки — такие как Flutter, Jetpack Compose, SwiftUI, React. Т.е. все самое передовое и современное — авангард вертски можно сказать. Чистый декларативный дедовский подход не удобен и существует только как легаси.
S>Что же касается управления этим UI — то что все-таки лучше на ваш взгляд?
S>Вот, поработал с BLoC. Вроде норм, но даже банальный диалог для подтверждения действия — как бы уже добавляет лишней работы. Т.е. прямо в логике (в bloc диалог вызвать нельзя), значит нужно добавить доп. состояние — требуется отобразить диалог, потом событие от диалога, потом обработку события и т.д. Как бы нет той простоты — когда 1 строчкой отобразил диалог и дальше продолжил выполнять код
S>Что вы используете и что лучшее на ваш взгляд?
Все зависит от приложения (количества форм, элементов ) и задач исходящих от клиента (есть дальнейшее развитие проекта или нет )
Например в WinForms можно с успехом использовать популярные архитектурные паттерны MVC , MVVM, MVP и в каждой конторе есть
свой велосипед (и не один !) к ним.
... Хорошо уметь читать между строк. Это иногда
приносит большую пользу
Здравствуйте, Janus, Вы писали:
S>>Что вы используете и что лучшее на ваш взгляд?
J>Все зависит от приложения (количества форм, элементов ) и задач исходящих от клиента (есть дальнейшее развитие проекта или нет ) J>Например в WinForms можно с успехом использовать популярные архитектурные паттерны MVC , MVVM, MVP и в каждой конторе есть J>свой велосипед (и не один !) к ним.
По умолчанию мы подразумеваем что каждый чел. в перспективе стремится сделать наиболее сложный, с максимальным количеством элементов проект — где требуется максимальная степень контроля — и берет фреймворк на вырост. И все более мелкие проекты использует только как плацдарм для подготовки к чем-то более важному, т.е. если даже фреймворк несколько избыточен для текущего проекта — несомненно опыт работы с ним будет важен для более сложных проектов.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Janus, Вы писали:
S>>>Что вы используете и что лучшее на ваш взгляд?
J>>Все зависит от приложения (количества форм, элементов ) и задач исходящих от клиента (есть дальнейшее развитие проекта или нет ) J>>Например в WinForms можно с успехом использовать популярные архитектурные паттерны MVC , MVVM, MVP и в каждой конторе есть J>>свой велосипед (и не один !) к ним.
S>По умолчанию мы подразумеваем что каждый чел. в перспективе стремится сделать наиболее сложный, с максимальным количеством элементов проект — где требуется максимальная степень контроля — и берет фреймворк на вырост. И все более мелкие проекты использует только как плацдарм для подготовки к чем-то более важному, т.е. если даже фреймворк несколько избыточен для текущего проекта — несомненно опыт работы с ним будет важен для более сложных проектов.
S>Так что же в таком ракурсе?
Тут не надо мудрить если честно. UI — самая "тупая" часть программы, если мы все правильно делаем. Накопать проблемы себе там — это нужно специально стараться.
Здравствуйте, Qulac, Вы писали:
Q>Тут не надо мудрить если честно. UI — самая "тупая" часть программы, если мы все правильно делаем. Накопать проблемы себе там — это нужно специально стараться.
Так было 20 лет назад. Сейчас UI в современных проектах — нередко превосходит по сложности бэкенд.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Qulac, Вы писали:
Q>>Тут не надо мудрить если честно. UI — самая "тупая" часть программы, если мы все правильно делаем. Накопать проблемы себе там — это нужно специально стараться.
S>Так было 20 лет назад. Сейчас UI в современных проектах — нередко превосходит по сложности бэкенд.
Здравствуйте, Qulac, Вы писали:
Q>Чем? Все также просто показывает.
Ну на старых проектах — да. На новых — есть поддержка оффлайн режима, возможность оффлайн и онлайн действий, псевдо-мгновенные операции (когда что-то заказал и оно как бы мгновенно исполнилось с рассчетом на то, что 99.5% подключений не обрываются — а потом отменилось, если подключение все-же оборвалось) и т.д. Добавьте сюда множество платформ и девайсов, адаптивную верстку и т.д.
А бекенд что? Ну положил в базу, послал по API и достал из базы — что там может быть сложного?
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Qulac, Вы писали:
Q>>Чем? Все также просто показывает.
S>Ну на старых проектах — да. На новых — есть поддержка оффлайн режима, возможность оффлайн и онлайн действий, псевдо-мгновенные операции (когда что-то заказал и оно как бы мгновенно исполнилось с рассчетом на то, что 99.5% подключений не обрываются — а потом отменилось, если подключение все-же оборвалось) и т.д. Добавьте сюда множество платформ и девайсов, адаптивную верстку и т.д.
S>А бекенд что? Ну положил в базу, послал по API и достал из базы — что там может быть сложного?
Здравствуйте, Shmj, Вы писали:
S>Вот, поработал с BLoC. Вроде норм, но даже банальный диалог для подтверждения действия — как бы уже добавляет лишней работы. Т.е. прямо в логике (в bloc диалог вызвать нельзя), значит нужно добавить доп. состояние — требуется отобразить диалог, потом событие от диалога, потом обработку события и т.д. Как бы нет той простоты — когда 1 строчкой отобразил диалог и дальше продолжил выполнять код
S>Что вы используете и что лучшее на ваш взгляд?
Мой текущий personal jesus — это JMIX-студия. Это как Дельфи, но для разработки корпоративных клиент-серверных JavaEE-систем и фулстэк-приложений.
Максимально, просто неимоверно максимально, ускоряет разработку production-ready корпоративного ПО и делает её очень комфортной, позволяя сосредоточиться на бизнес-сущностях и их бизнес-логике, а не потонуть в мириадах строк шаблонного boiler-plate кода. Это примерно как в своё время появился Дельфи как откровение после виндузового морока с MFC — ты просто лепишь на форму поля и кнопки, создаёшь обработчики событий, х*як-х*як — и десктоп-приложуха готова. Если в JMIX нужно вызвать диалог, даже асинхронный с background-прогресс-баром — вызываешь его в коде, без лишней писанины по десяти разным местам.
Архитектура там Server-Side MVC на основе Vaadin.
Здравствуйте, Qulac, Вы писали:
S>>А бекенд что? Ну положил в базу, послал по API и достал из базы — что там может быть сложного? Q>Это не сложность.
Оно дьявол как всегда в деталях. И человечество делает максимально сложно, насколько только возможно. Но не сложнее чем доступно среднему человеку все-же. Т.е. в итоге после великого раскола — на фронт и бек, когда это стало отдельными специализациями — сложность фронта увеличилась на порядок примерно. Бек сейчас только отдает JSON, по сути.
В конечном итоге во всех сферах деятельности человечество приходит +- к одинаковой сложности, кроме деятельности элитарной (наука и пр.) — где могут работать лишь избранные.
S>По умолчанию мы подразумеваем что каждый чел. в перспективе стремится сделать наиболее сложный, с максимальным количеством элементов проект — где требуется максимальная степень контроля — и берет фреймворк на вырост. И все более мелкие проекты использует только как плацдарм для подготовки к чем-то более важному, т.е. если даже фреймворк несколько избыточен для текущего проекта — несомненно опыт работы с ним будет важен для более сложных проектов.
Ты никогда не занимался разработкой под заказчика. Судя по твоим постам, единственное что ты хорошо умеешь делать , это пустая болтовня на форуме
Никому не нужно усложнять проект , заказчику вообще фиолетово какой фреймворк внутри проекта ( Иногда бывает что , фреймворк оговорен в ТЗ или есть внешний аудит ) Никто в коммерческой разработке не занимается искусством ради искусства и освоением новых технологий на проектах заказчика . Для этого существуют pet проекты.
... Хорошо уметь читать между строк. Это иногда
приносит большую пользу
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Qulac, Вы писали:
Q>>Чем? Все также просто показывает.
S>Ну на старых проектах — да. На новых — есть поддержка оффлайн режима, возможность оффлайн и онлайн действий, псевдо-мгновенные операции (когда что-то заказал и оно как бы мгновенно исполнилось с рассчетом на то, что 99.5% подключений не обрываются — а потом отменилось, если подключение все-же оборвалось) и т.д.
Раскрой подробнее каким образом этот фунционал относится UI
... Хорошо уметь читать между строк. Это иногда
приносит большую пользу
Здравствуйте, Janus, Вы писали:
J>Ты никогда не занимался разработкой под заказчика. Судя по твоим постам, единственное что ты хорошо умеешь делать , это пустая болтовня на форуме
20 лет только этим и занимаюсь.
J> Никому не нужно усложнять проект , заказчику вообще фиолетово какой фреймворк внутри проекта ( Иногда бывает что , фреймворк оговорен в ТЗ или есть внешний аудит ) Никто в коммерческой разработке не занимается искусством ради искусства и освоением новых технологий на проектах заказчика . Для этого существуют pet проекты.
Вот по этому и стоит выбирать фреймворк на вырост — возможно даже для конкретно этого проекта он великоват, но зато у тебя будет рука набита когда придется делать более сложные проекты. В чем тут проблема?
Здравствуйте, Janus, Вы писали:
S>>Ну на старых проектах — да. На новых — есть поддержка оффлайн режима, возможность оффлайн и онлайн действий, псевдо-мгновенные операции (когда что-то заказал и оно как бы мгновенно исполнилось с рассчетом на то, что 99.5% подключений не обрываются — а потом отменилось, если подключение все-же оборвалось) и т.д.
J>Раскрой подробнее каким образом этот фунционал относится UI
Ну смотря что такое UI по-вашему. Тонкий моб. клиент, который тупо дергает API сайта — да и сами Web-клиенты сейчас такие — что это как не UI?
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Janus, Вы писали:
J>>Ты никогда не занимался разработкой под заказчика. Судя по твоим постам, единственное что ты хорошо умеешь делать , это пустая болтовня на форуме
S>20 лет только этим и занимаюсь. У тебя очень странные вопросы для человека с 20 летнем стажем коммерческой разработки .
J>> Никому не нужно усложнять проект , заказчику вообще фиолетово какой фреймворк внутри проекта ( Иногда бывает что , фреймворк оговорен в ТЗ или есть внешний аудит ) Никто в коммерческой разработке не занимается искусством ради искусства и освоением новых технологий на проектах заказчика . Для этого существуют pet проекты.
S>Вот по этому и стоит выбирать фреймворк на вырост — возможно даже для конкретно этого проекта он великоват, но зато у тебя будет рука набита когда придется делать более сложные проекты. В чем тут проблема?
Проблема в качестве итогового продукта и времени затраченном на разработку . У тебя есть фреймворк понятный твоей команде + 100500 наработок (тестов) на этом фреймворке от предыдущих проектов, позволяющие выдать клиенту качественный прототип продукта через условную неделю. Прыгать на граблях не очень благодатное занятие в коммерческой разработке .
... Хорошо уметь читать между строк. Это иногда
приносит большую пользу
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Janus, Вы писали:
S>>>Ну на старых проектах — да. На новых — есть поддержка оффлайн режима, возможность оффлайн и онлайн действий, псевдо-мгновенные операции (когда что-то заказал и оно как бы мгновенно исполнилось с рассчетом на то, что 99.5% подключений не обрываются — а потом отменилось, если подключение все-же оборвалось) и т.д.
J>>Раскрой подробнее каким образом этот фунционал относится UI
S>Ну смотря что такое UI по-вашему. Тонкий моб. клиент, который тупо дергает API сайта — да и сами Web-клиенты сейчас такие — что это как не UI?
ты не слезай с темы
S>>> На новых — есть поддержка оффлайн режима, возможность оффлайн и онлайн действий, псевдо-мгновенные операции (когда что-то заказал и оно как бы мгновенно исполнилось с рассчетом на то, что 99.5% подключений не обрываются — а потом отменилось, если подключение все-же оборвалось) и т.д.
где здесь UI ?
... Хорошо уметь читать между строк. Это иногда
приносит большую пользу
Здравствуйте, Shmj, Вы писали:
S>20 лет только этим и занимаюсь.
Этим — болтовнёй на форуме?
S>Вот по этому и стоит выбирать фреймворк на вырост — возможно даже для конкретно этого проекта он великоват, но зато у тебя будет рука набита когда придется делать более сложные проекты. В чем тут проблема?
Переход количества в качество — слыхали? Поинтересуйтесь при случае у GPT, что это такое.
Мы в дебри языков лазали на первом курсе. Ну чтобы понять ту или иную возможность языка. Решить задачу тогда считалось вторичным.
А сейчас нужно задачи рашать. И я не буду для небольшой GUI-программы делать интерфейс на HTML, а сделаю на чём-нибудь попроще. Всё определяется решаемой задачей и только ею.
Здравствуйте, Janus, Вы писали:
S>>20 лет только этим и занимаюсь. J> У тебя очень странные вопросы для человека с 20 летнем стажем коммерческой разработки .
Ну значит знай что бывает и такое — будешь знать что чел. с 20 летним стажем, который только этим и занимался и другого ничего не умеет — может так мыслить. Иногда стаж не решает — Природа первична и она всех наделила разными способностями, ничего стесняться этого. Кто-то вообще дауном родился — и что такого?
S>>Вот по этому и стоит выбирать фреймворк на вырост — возможно даже для конкретно этого проекта он великоват, но зато у тебя будет рука набита когда придется делать более сложные проекты. В чем тут проблема?
J>Проблема в качестве итогового продукта и времени затраченном на разработку . У тебя есть фреймворк понятный твоей команде + 100500 наработок (тестов) на этом фреймворке от предыдущих проектов, позволяющие выдать клиенту качественный прототип продукта через условную неделю. Прыгать на граблях не очень благодатное занятие в коммерческой разработке .
Если фреймворк с запасом — на вырост — не будет так уж сильно больше времени затрачено. Зато команда будет более подготовлена. А с учетом того что все берут фреймворк на вырост — т.к. сидеть в болоте никто не хочет — то найти спецов, которые уже имеют опыт работы с навороченным фреймворком — даже проще.
