Может быть) Но это все равно немного другая реализация архитектуры. Я не создаю сам отдельно контроллер и представление. Я использую классы, строю на них свое приложение. А за остальное отвечает фреймворк.
Новое - единые переменные для серверного и клиентского кода, работа, как с десктопным приложением. И отказ от явно выраженной архитектуры MVC, декларирование стандарта CMA, когда классы рождают массив метаданных, которые могут быть преобразованы во что угодно: в DOM, в ответ API, в данные для построения мобильного приложения. И сами по себе метаданные могут существовать без исходного кода приложения.
Про кастомную верстку - пример в статье.
Сторонние компоненты можно интегрировать через прямое подключение их к UI
Многопоточность с 7-й PHP версии можно внедрить в приложение. Для тех разработок, где оно критично, лучше, конечно, PHP не использовать. Я в месяц сдаю клиентам 2-4 web-приложения. И пока многопоточность никому не потребовалась.
Мне на это нечего ответить. Возможно, Вы во всем правы. По идее, надо бы изловить дурака (меня) и не давать больше кодить. Так? Просто другого практического вывода из всего написанного я не вижу. Можно написать WMS на laravel за пару вечеров? Конечно! Можно на .net Даже на старом добром php builder. Что ж, стоит оставить в мире только одно средство разработки, а остальные запретить? Не надо никогда и никому пытаться изобретать велосипед? Я в силу своей ограниченности предполагаю, что многое из того, что сейчас считается стандартом, когда-то было велосипедом и "создавало проблемы для заказчика". Да и сейчас создаёт! Если система создана на .net, а новый специалист поддержки с ним не знаком, то это - проблема заказчика! Да даже если и знаком: разобраться в суровом проекте на любом языке достаточно сложно. Я когда-то работал с .Step7 и Reduce, посмотрели бы Вы проекты, написанные на них и попытались разобраться! С другой стороны, та же wms на lotis сперва вызвала шок у ихнего пхпшника: у всех же страх перед чем-то новым, но через 10 минут он уже вносил свои модификации в систему. Laravel он не знал и вряд ли разобрался бы за 10 минут. Про любовь к зависимостям - ну, хорошо! Если есть задача, их требующая, то давайте их использовать. Вы вот пишите про пдф и эксель. А что если заказчик попросит добавить в проект работу с Ардуино или замутить блокчейн? Не может быть единого средства на все случаи жизни! В конце концов, и к лотис прикрутить композер тоже не такая уж сложная проблема.
Ключевое "в общепринятом понимании". А почему оно общепринято? Технология ради какой-то идеи? Я придерживаюсь другого правила: автоматизация нужна ровно настолько, чтобы приносить прибыль компании. Все сверх этого - попытка сохранить старый холодильник на балконе: вдруг пригодится! Удивительно, но в крутой западной корпорации зачастую можно встретить еще систему учета на 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 с учетом персональных требований заказчика. Назовите еще какие-то инструменты разработки с таким же быстрым входом, позволяющие это делать.
Ну, я во фрилансе уже 20 лет. Приходится в одиночку делать большие проекты по типу CRM с нуля или WMS. Как правило, сроки ограничены. Поэтому и задался этим вопросом: как быстро ваять WEB-приложения, не раскидывая логику по разным файлам и средствам разработки.
Да, слоистая архитектура в WEB, по сути, атавизм из 90-х. Берусь утверждать, что в ближайшем десятилетии от нее отойдут. Переход на классы - один из вариантов.
Что можно предлдожить по хакам? Я сейчас портирую жэто на node. Получается интересно: весь клиентский код на объектах. Один язык, одни переменные. Может, просто не употреблять слово хак?:)
Для просто сайта хаки и не нужны, думаю. Это ж для реализации бизнес сущностей: справочников, документов, регистров. Я занимаюсь WEB-приложениями в основном, не сайтами.
Ахах. Ну я еще тот динозавр, да. А какой может быть вариант без хаков? Вообще, с ними все предполагалось просто. У любого метода есть три хака: check - выполнять или нет, before - редактировать параметры, on - после выполнения. Если есть метод obj.morkovka(), то можно определить шесть хаков: три клиентских, три серверных. checkmorkovka(), beforemorkovka(), onmorkovka()
У нас очень гармоничные отношения)
Может быть) Но это все равно немного другая реализация архитектуры. Я не создаю сам отдельно контроллер и представление. Я использую классы, строю на них свое приложение. А за остальное отвечает фреймворк.
Новое - единые переменные для серверного и клиентского кода, работа, как с десктопным приложением. И отказ от явно выраженной архитектуры MVC, декларирование стандарта CMA, когда классы рождают массив метаданных, которые могут быть преобразованы во что угодно: в DOM, в ответ API, в данные для построения мобильного приложения. И сами по себе метаданные могут существовать без исходного кода приложения.
Про кастомную верстку - пример в статье.
Сторонние компоненты можно интегрировать через прямое подключение их к UI
Многопоточность с 7-й PHP версии можно внедрить в приложение. Для тех разработок, где оно критично, лучше, конечно, PHP не использовать. Я в месяц сдаю клиентам 2-4 web-приложения. И пока многопоточность никому не потребовалась.
Под node портирую без jQuery. Ванильный js) Под UI можно взять любой фреймворк, нормальный и не очень. Цель была использовать минимум зависимостей.
Мне на это нечего ответить. Возможно, Вы во всем правы. По идее, надо бы изловить дурака (меня) и не давать больше кодить. Так? Просто другого практического вывода из всего написанного я не вижу. Можно написать WMS на laravel за пару вечеров? Конечно! Можно на .net Даже на старом добром php builder. Что ж, стоит оставить в мире только одно средство разработки, а остальные запретить? Не надо никогда и никому пытаться изобретать велосипед? Я в силу своей ограниченности предполагаю, что многое из того, что сейчас считается стандартом, когда-то было велосипедом и "создавало проблемы для заказчика". Да и сейчас создаёт! Если система создана на .net, а новый специалист поддержки с ним не знаком, то это - проблема заказчика! Да даже если и знаком: разобраться в суровом проекте на любом языке достаточно сложно. Я когда-то работал с .Step7 и Reduce, посмотрели бы Вы проекты, написанные на них и попытались разобраться! С другой стороны, та же wms на lotis сперва вызвала шок у ихнего пхпшника: у всех же страх перед чем-то новым, но через 10 минут он уже вносил свои модификации в систему. Laravel он не знал и вряд ли разобрался бы за 10 минут. Про любовь к зависимостям - ну, хорошо! Если есть задача, их требующая, то давайте их использовать. Вы вот пишите про пдф и эксель. А что если заказчик попросит добавить в проект работу с Ардуино или замутить блокчейн? Не может быть единого средства на все случаи жизни! В конце концов, и к лотис прикрутить композер тоже не такая уж сложная проблема.
Я не знаю, что такое, rage bait. По идее, это должно бесить ещё больше)
Почему? Не лучше.
Ключевое "в общепринятом понимании". А почему оно общепринято? Технология ради какой-то идеи? Я придерживаюсь другого правила: автоматизация нужна ровно настолько, чтобы приносить прибыль компании. Все сверх этого - попытка сохранить старый холодильник на балконе: вдруг пригодится! Удивительно, но в крутой западной корпорации зачастую можно встретить еще систему учета на 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 с учетом персональных требований заказчика. Назовите еще какие-то инструменты разработки с таким же быстрым входом, позволяющие это делать.
Вряд ли. Во всяком случае, это голословно. Приведите пример того, что, по Вашему, считается в отрасли сложной бизнес логикой.
Готовлю к публикации приложение для производственного учета на предприятии.
Ну, я во фрилансе уже 20 лет. Приходится в одиночку делать большие проекты по типу CRM с нуля или WMS. Как правило, сроки ограничены. Поэтому и задался этим вопросом: как быстро ваять WEB-приложения, не раскидывая логику по разным файлам и средствам разработки.
Да, слоистая архитектура в WEB, по сути, атавизм из 90-х. Берусь утверждать, что в ближайшем десятилетии от нее отойдут. Переход на классы - один из вариантов.
Вижу, что многие комментаторы просто поленились заглянуть на гитхаб.
Все это рализовано, конечно. На гитхабе полная документация с примерами.
Что можно предлдожить по хакам? Я сейчас портирую жэто на node. Получается интересно: весь клиентский код на объектах. Один язык, одни переменные. Может, просто не употреблять слово хак?:)
Для просто сайта хаки и не нужны, думаю. Это ж для реализации бизнес сущностей: справочников, документов, регистров. Я занимаюсь WEB-приложениями в основном, не сайтами.
Ахах. Ну я еще тот динозавр, да. А какой может быть вариант без хаков? Вообще, с ними все предполагалось просто. У любого метода есть три хака: check - выполнять или нет, before - редактировать параметры, on - после выполнения. Если есть метод obj.morkovka(), то можно определить шесть хаков: три клиентских, три серверных. checkmorkovka(), beforemorkovka(), onmorkovka()