Обновить

Комментарии 11

А не староват ли MFC для новый разработок? Почему не веб-интерфейс?

А как связываться с контроллерами? Это должно быть приложение, на WinRT или Win32 или любой другой, но именно приложение под любую операционную систему. А MFC - это скорость разработки. Мне очень комфортно в ней работать, писать много, но и выход в рабочую программу быстрый.

Да, приложение (backend) нужно написать, и frontend (на стороне броузера). Зато приложение можно один экземпляр установить и с многих клиентов пользоваться.
Можно ИИ использовать чтобы быстро все написать.
Вот пример OPC UA клиента: https://ide.opcfy.io
Использован OPC UA Rust SDK в приложении, и PrimeReact для фронта, и Cursor + Claude Code

Хотя от конкретных условий, требований и имеющихся навыков / библиотек зависит, почему бы не использовать старый добрый MFC.

В данном приложении так и получается: разделена серверная и клиентская часть. Серверная часть работает напрямую с контроллерами и льет данные на сервер SQL, а клиенты, подключаются к SQL, считывают данные и сохраняют рецепты на сервере. Есть в планах написать программу для андроида с работой через SQL, но это будет позже и тоже будет самописная, уже такую наподобие писал на джаве.

Быстрая разработка это только готовая скада с готовыми драйверами, мышекликательной визуализацией итп.

А самописки - прошлый век. Реально, времен бухгалтерий на дельфи.

Но есть ряд задач, который скады не покрывают или покрывают дорогими опциями, например сложное архивирование с расчётом всяких кубов агрегаций или пост обработка данных. Вот тут такие решения в тему

Всё было сделано сначала на WinCC (и программы на контроллер тоже нужно было написать). Но рецепты в WinCC очень отвратительные и в последних версиях нет возможности встроить "бесплатные" версии. Поэтому пришлось "пилить" самоделку.

Да и конечно пост обработка данных "на лету" очень показательна. Тут она реализована в полной мере. Расписывает шаги персонала от начала и до конца.

Wincc имеет возможность вызова внешних dll из С-скриптов, там можно всё

Неподалёку от меня есть очень показательная система, которая разрастается на 1Гб объема базы SQL Server в неделю... Прошло больше полгода, сервера уже не хватает... Память на 378 Гб кончилась, думают убежать в облако... беда бессмысленного программирования ради красивых картинок.

Я не говорю, то такое решение подойдет для всех. Но те задачи, которые ставились, программа выполняет. Есть возможность роста. Я, например, подумываю сейчас объединить свичи и прочее комп. оборудование через OPC UA.

По это будет поле темной темы для своих программ... которое уже сделано на 90%.

Неподалёку от меня есть очень показательная система, которая разрастается на 1Гб объема базы SQL Server в неделю... Прошло больше полгода, сервера уже не хватает... Память на 378 Гб кончилась, думают убежать в облако... беда бессмысленного программирования ради красивых картинок.

Не вижу связи с обсуждаемой темой.

Ну так не надо писать 1гб в неделю и пытаться все хранить в памяти.

Это от средств разработки не зависит

Зависит не только от кривизны рук программиста, но и от используемой системы программирования.

Та программа написана на Java and PostgreSQL (новые супер технологии), и периодически зависает с задачами по 1,5 Гб в памяти... при задаче принять от 20-ти устройств пакет 100 байт раз в 5 секунд и отправить его в 1С.

Как раз от радиуса рук и зависит.

Какие то ограничения технологии накладывают, но не насколько.

Яве 30+ лет, постгресу тоже много, не такие они и новые, с ними уже отработаны методики адекватной работы.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации