Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 32
Есть ссылка на пример ?
Очень интересно. Лет 20-ть назад такое уже было, но сообщество отказалось от этого пути. Я и сам таким баловался по-молодости. Так что это, увы, не новая парадигма..
Как проекта для своего фриланса - это нормально, но для большой компании вряд ли подойдёт - по целому ряду причин.
Фреймворк для быстрой разработки сложных бизнес-приложений
Я полагаю, что ваше представление о сложной бизнес-логике кардинально отличается от того, что принято таковой считать в отрасли.
Вряд ли. Во всяком случае, это голословно. Приведите пример того, что, по Вашему, считается в отрасли сложной бизнес логикой.
Начать и закончить можно прям с этого:
Полное отсутствие доменного слоя, вся ваша бизнес логика это анонимные замыкания прямо внутри UI контроллеров. DataView одновременно и ui компонент, и контроллер, и репозиторий.
А так, у вас просто нет даже базовой инфраструктуры для этого:
- нет Composer (как минимум для автозагрузки по psr-4)
- нет router
- нет DI
- нет REST API
- сессии у вас нативные - как будем горизонтально масштабироваться?
- с БД прям беда - нет полноценной ORM, запросы не подготовлены(!), нет миграций, мускуль прибит гвоздями, нет транзакций - в LTS\Stock::update гоним запросы через foreach (другой важный вопрос - почему не одним запросом) и молимся тихонечко, чтоб ничего не упало посередине
- нет кэширования
- нет CSRF, нет санитизации входных данных
- нет даже базовых юнит тестов
Это прям по верхам... Это не фреймворк в общепринятом понимании, а что-то типа RAD для прототипирования crud интерфейсов.
Ключевое "в общепринятом понимании". А почему оно общепринято? Технология ради какой-то идеи? Я придерживаюсь другого правила: автоматизация нужна ровно настолько, чтобы приносить прибыль компании. Все сверх этого - попытка сохранить старый холодильник на балконе: вдруг пригодится! Удивительно, но в крутой западной корпорации зачастую можно встретить еще систему учета на FoxPro, которая работает и всех устраивает. Но российскому предпринимателю, продающему пирожки в переходе, конечно же нужно 1С:ERP! На всякий случай, вдруг пригодится!
Теперь по поводу критики. Она имеет место быть, потому что Вы сейчас говорите об Enterprise-приложениях. Давайте тогда уж критиковать автомобили: они же не летают! Обратите внимание, как я позиционирую LOTIS:
Фреймворк для быстрой разработки бизнес-приложений одним разработчиком или небольшой командой без необходимости разделять логику на клиент/сервер. Целевая аудитория - клиенты фрилансеров, в основном средний и мелкий бизнес. Хотя я перечислял и крупных клиентов, для которых решал задачи.
В LOTIS нет отдельного доменного слоя в классическом понимании DDD. Но это осознанный выбор, а не недостаток. Для большинства бизнес-приложений, которые заказывают (учет товаров, производственный, складской учет, планирование закупок и продаж, работа с клиентами, система документооборота, отчеты), доменная логика тесно связана с UI. В таких случаях разделение на слои часто приводит к избыточной сложности. В LOTIS вы можете создать отдельный доменный слой при необходимости — фреймворк не мешает этому. Но он не навязывает сложную структуру там, где она не нужна.
Про composer я писал. Это тоже осознанный выбор: как можно меньше зависимостей. LOTIS использует spl_autoload_register для автоматической загрузки классов. Это упрощает подключение — достаточно одного файла lotis.php. Для проектов, где нужна автозагрузка по PSR-4, интеграция с Composer возможна, но не обязательна.
Про модель MVC. И об этом я тоже писал! Отказ от этой модели - опять же, сознательный выбор. А почему, собственно, MVC - некий эталон? Вы же сами упомянули парочку других архитектур, микросервисная, к примеру. Можно вспомнить событийную - здравствуй Qt!. Давайте и его критиковать за то, что он не поддерживает MVC. Я предлагаю отказаться от MVC в WEB разработке, потому что многослойно и далеко не наглядно. Вместо этого предлагаю модель CMA и наглядность десктопного приложения.
Router и REST API... Опять технология ради технологии. Зачем? LOTIS фокусируется на полном приложении, а не на API-first подходе. Для проектов, где нужен REST API, есть другие фреймворки. LOTIS решает задачу построения целостного приложения без разбивки на микросервисы. Почему, например, не требовать с таким же успехом обеспечивать REST API для Windows Form приложения?
То же относится и к масштабированию. Для подавляющего большинства проектов, на которые ориентирован LOTIS, это не проблема. Если масштабирование необходимо, можно использовать кастомные обработчики сессий.
О! Вы, вероятно, сложность приложения оцениваете с точки зрения именно масштабирования и применения различных крутых технологий? Тогда мы говорим о разном. Для меня сложность - это прежде всего сложность бизнес задач, которые мое приложение решает и сложность бизнес процессов, которые мы автоматизируем.
Есть ли куда стремиться? Конечно. И с Вашим опытом критического взглада на то, как должно быть, думаю, LOTIS только бы выиграл. Другое дело, что большинство критиков почему-то не любят ничего создавать и не хотят замечать потенциал там, где он есть. И это проблема. Давайте так, любой мидл за пару вечером с помощью LOTIS может создать систему учета по типу WMS или CRM с учетом персональных требований заказчика. Назовите еще какие-то инструменты разработки с таким же быстрым входом, позволяющие это делать.
Удивительно, но в крутой западной корпорации зачастую можно встретить еще систему учета на FoxPro, которая работает и всех устраивает. Но российскому предпринимателю, продающему пирожки в переходе, конечно же нужно 1С:ERP! На всякий случай, вдруг пригодится!
Тут всё очень просто. Если в вашей стране за последние 30 лет законы не менялись, то вы вполне можете сидеть на 30-летнем коде FoxPro. А вот если у вас законы и требования к бухучёту меняются по пять раз за год, самим допиливать свою FoxPro становится гораздо дороже, чем перейти на 1С с централизованным обновлением.
Кстати, а сайт o-planet не на вашем Lotis’е написан? а то какой-то он кривоватый.
Про FoxPro прям сразу навеяло "дед курил и дожил до 90 лет". Легаси системы типа FoxPro это техдолг с которым мирятся, а не пример для подражания. Никто не пишет новые системы на FoxPro в 2026.
Я не очень понимаю такую сущность как "разделять логику на клиент/сервер", полагаю, что вы имеете в виду разделение на фронтенд и бэкенд. Бизнес-логика всегда живет на сервере. На клиенте ui-логика (показать/скрыть, валидация для UX и т.д.). Это не "разделение логики", а разделение по средам выполнения. Говорить "без необходимости разделять логику на клиент/сервер" значит допускать, что бизнес-логика может быть на клиенте. А она не должна. "Не нужно писать JS отдельно" - это можно преподнести как dx фичу, но "без необходимости разделять логику" это архитектурный антипаттерн. Звучит как маркетинговый лозунг "В нашем авто нет сложного разделения на двигатель и салон! Вы подливаете бензин прямо за рулем, а выхлопная труба приятно греет спину."
DDD != доменный слой. Доменный слой это просто отделение бизнес-логики от представления. Хоть функцией, хоть классом-сервисом. Даже тривиальный Service Layer уже будет доменным слоем. "доменная логика тесно связана с UI" фундаментальное заблуждение - расчет себестоимости, проводка документа, пересчет остатков - все это бизнес-логика, которая никак не связана с тем, как выглядит форма.
Про жизнь без composer. Вы путаете отсутствие зависимостей с отсутствием возможности их подключить. Composer можно юзать и без внешних пакетов, только для PSR-4 автозагрузки. Зависимости не нужны ровно до того момента, когда заказчик попросит "А прикрути-ка сюда генерацию накладных в PDF, парсинг прайсов из Excel и интеграцию со шлюзом оплаты". Я правильно понимаю, в мире LOTIS разработчик уходит в закат писать свой PDF-генератор или качает либу и костылит ее подключение вручную?
У вас невалидные данные о QT. Зачем противопоставлять событийную архитектуру и MVC, это же не взаимоисключающие вещи. Qt одновременно событийно-ориентирован и реализует Model/View (не MVC т.к. это специфика GUI фреймворков как я понял). Неудачная аналогия с WinForms, это же ui тулза которая живет поверх .NET, в котором уже есть и DI, ORM (EF), транзакции, авторизация, тесты и еще куча свистоперделок которые вы так ненавидите.
Про "сложность бизнес задач" трудно не согласиться. Покажите, а чем LOTIS помогает с этой сложностью? Пока единственный бизнес-компонент Stock не умеет банально обернуть массовый UPDATE в транзакцию. Складской учет в котором при обрыве соединения теряются остатки - это конечно, сложная бизнес-задача. Но решенная она после этого не становится.
Давайте так, любой мидл за пару вечером с помощью LOTIS может создать систему учета по типу WMS или CRM с учетом персональных требований заказчика. Назовите еще какие-то инструменты разработки с таким же быстрым входом, позволяющие это делать.
За те же два вечера мидл на Filament (Laravel) получит WMS с авторизацией, RBAC-ролями, миграциями, транзакциями, экспортом в Excel/PDF, аудит-логом и REST API. Вопрос еще в том, что будет на третий вечер, когда заказчик скажет: "а добавь авторизацию", "а сделай так, чтоб если свет моргнет накладная не сохранялась наполовину", "а прикрути экспорт в Excel". В Laravel это composer require и полчаса работы. В LOTIS - экзистенциальный кризис. "Любой мидл за два вечера" не уникальное преимущество LOTIS. Разница в том, что за теми двумя вечерами в одном случае продакшн система, а в другом очень быстро написанная "проблема" заказчика. Вполне реально сделать простую CRM за пару вечеров (в обнимку с LLM за один) и при этом не жертвовать безопасностью, архитектурой и здравым смыслом.
Мне на это нечего ответить. Возможно, Вы во всем правы. По идее, надо бы изловить дурака (меня) и не давать больше кодить. Так? Просто другого практического вывода из всего написанного я не вижу. Можно написать WMS на laravel за пару вечеров? Конечно! Можно на .net Даже на старом добром php builder. Что ж, стоит оставить в мире только одно средство разработки, а остальные запретить? Не надо никогда и никому пытаться изобретать велосипед? Я в силу своей ограниченности предполагаю, что многое из того, что сейчас считается стандартом, когда-то было велосипедом и "создавало проблемы для заказчика". Да и сейчас создаёт! Если система создана на .net, а новый специалист поддержки с ним не знаком, то это - проблема заказчика! Да даже если и знаком: разобраться в суровом проекте на любом языке достаточно сложно. Я когда-то работал с .Step7 и Reduce, посмотрели бы Вы проекты, написанные на них и попытались разобраться! С другой стороны, та же wms на lotis сперва вызвала шок у ихнего пхпшника: у всех же страх перед чем-то новым, но через 10 минут он уже вносил свои модификации в систему. Laravel он не знал и вряд ли разобрался бы за 10 минут. Про любовь к зависимостям - ну, хорошо! Если есть задача, их требующая, то давайте их использовать. Вы вот пишите про пдф и эксель. А что если заказчик попросит добавить в проект работу с Ардуино или замутить блокчейн? Не может быть единого средства на все случаи жизни! В конце концов, и к лотис прикрутить композер тоже не такая уж сложная проблема.
Видимо только на постсоветском пространстве кто то еще возится с php, все остальные давно про него забыли как страшный сон. как по мне мертворожденная субстанция, пет проект для самоутверждения.
Посмотрите в сторону SSR, например, Blazor
Могу сказать сразу. Возможно создание собственного велосипеда в одиночку это круто и увлекательно, но я думаю надо смотреть в ту сторону, где велосипед уже создан и не в одного, а целой компанией на 1000 сотрудников.
Ваша идея понятна, но уже существует ряд открытых бесплатных решений для всей этой ERP чепухи, сразу с UI конструктором и остальным. Говорить и рекламировать что-то не буду. Статья очень сильно тянет на нейрослоп, схемы можно же было нарисовать и в виде изображений вставить.
позволю немного критики. или критиканства, уж простите.
(1) я не увидел новой парадигмы. именно новой. сам я джавист, и простите, я видел тот же jsf с "сервер сайд рендерингом" и невнятной вёрсткой формы на xml. ужасы типа vaadin со всеми вытекающими. даже я сам приложил руку к увеличению безобразий.
вы правильно отмечаете, что фейсбучная разработка по модели рест+тяжелый js настойчиво подталкивают к "утеканию бизнес логики на клиента". я бы ещё добавил "по факту раздуваемые" трудозатраты, но это уже "надо доказывать". но не суть. вопрос в том, а в чем парадигма?
(2) как в вашем фреймворка сделать кастомную верстку?
(2.2) как интегрировать в ваш фоеймворк работу со сторонними js-клмпонентами? например, я хочу интегрировать в систему яндекс-карты?
(3) простите, но пыха для бизнес приложений - ... выглядит сомнительно. конечно, если вы останетесь в модели рест-запросов и стейтлесс-(микро?)сервисов, без фоновых процессов и многопоточного серверного кода, кеширования в памяти... то конечно, "почему бы да"... но потолок для таких систем весьма не высок ( не, может в пыхе что то и придумали, простите, я ушёл на джаву примерно когда "не состоялся пхп 6 с многопоточностью"). в общем я к чему - разработка бизнес-прилодений с тяжёлой бизнеслогикой и сложными сценариями на языке без многопоточности... сомнительно это выглядит). не говоря о необходимости стандартизации языка, обеспечения гарантий обратной совместимости (как же писать бизнес приложение, если у него срок жизни равен сроку поддержки текущего компилятора?) и статической типизации ( в больших проектах это оооочень сильно помогает избежать кучи ошибок), но это уже совершенно другой разговор.
Новое - единые переменные для серверного и клиентского кода, работа, как с десктопным приложением. И отказ от явно выраженной архитектуры MVC, декларирование стандарта CMA, когда классы рождают массив метаданных, которые могут быть преобразованы во что угодно: в DOM, в ответ API, в данные для построения мобильного приложения. И сами по себе метаданные могут существовать без исходного кода приложения.
Про кастомную верстку - пример в статье.
Сторонние компоненты можно интегрировать через прямое подключение их к UI
Многопоточность с 7-й PHP версии можно внедрить в приложение. Для тех разработок, где оно критично, лучше, конечно, PHP не использовать. Я в месяц сдаю клиентам 2-4 web-приложения. И пока многопоточность никому не потребовалась.
отказ от явно выраженной архитектуры MVC, декларирование стандарта CMA, когда классы рождают массив метаданных, которые могут быть преобразованы во что угодно
“Массив метаданных” порождается контроллером (contoroller). “Преобразуется во что угодно” в нужном виде (view). А к моделям (model) контроллер обращается для получения исходных данных.
Так что никуда вы от MVC не ушли.
Для любопытствующих - вот: https://thorm.dev/
Тогда уж лучше это использовать https://github.com/atk4/ui
Одна из проблем такого рода проектов (у меня самого таких компонент в старом портфолио валяется штук 20), что они выглядят красиво, но ничего кроме удобства для самого фрилансера не несут.
Я просто зашёл на демку и сделал примитивную проверку...
Опять же, ничего не имею против таких проектов, но...
Если бы я сегодня снова вернулся бы во фриланс, то взял бы что-то вроде http://filamentphp.com
Все это класно пока не видиш Ларавел с кучей замвисимостей и еше большей магией.
Да, согласен, там свои заморочки есть и немало.
Но главный плюс - это то, что можно сосредоточиться на разработке проекта. А фрилансер, который помимо проекта для клиента "пилит" ещё и свою библиотеку компонент - тратит кучу своего времени на её поддержку, устранение багов, улучшение и т.д. Я в какой-то момент от всего этого отказался.
Всегда можно взять старый добрый https://www.jeasyui.com/ с моим враппером для php https://github.com/Vladzimir/phpEasyUI
Почему? Не лучше.
Ну ответ касался именно thorm.dev а на счет atk4 - там хоть полноценный UI присутствует.
Почему JQuery а не htmx+alpinejs? Почему для UI не взяли нормальный css-феймворк, например Bulma?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
LOTIS: Новая парадигма WEB-разработки для бизнес-приложений