Вот Вы уже почти поняли мою идею. Но проблема в том что и sql и язык хранимых процедур и возможности меняются от СУБД к СУБД. И хоть и sql достаточно мощен чтобы вернуть из базы все в нужном виде, постобработка и вычисления иногда все же нужны.
Поэтому первое — нужен единый sql синтаксический сахар (сделаем язык общим для всех СУБД и заодно упростим его)
Второе — придумаем поддержку постобработчиков.
Приведу простой пример (отдалённый от жизни): вывести 10 последних зарегистрированных админа, если они зарегились в одном месяце:
Скрипт будет такой:
@lastTenAdmins = select from users
id.desc,
name
join user_group
join groups
name
where name = 'admin'
limit 10;
%regInSameMonth @lastTenAdmins;
Функция regInSameMonth в моем случае уже написана на php которая принимает результат выполнения запроса @lastTenAdmins.
Ни во что. Я хочу вообще избавиться от backend составляющей в ходе разработки. И от всех backend фрейморков как следствие. Использовать только frontend фреймворк, а в случае где необходимо использовать базу данных обращаться к ней напрямую, заставляя все необходимые данные отдавать уже в нужной структуре во фронтенд. Для этого создать какой нибудь язык типа suql который будет общим для всех СУБД. Который не просто облегчал синтаксис sql а и мог его расширить
Ваш сарказм понятен. Я действительно описал так, что можно так подумать. Но я топлю за то чтобы на backend стороне больше ответственности возложить на базу данных (логика и тд). Вы скажете что не разумно, так как СУБД может меняться. Тогда сделать по принципу как сделали в react native, где код компилится под определённую платформу. Собственно все дело в моем почёте к react, и то что он не похож на это однотипное г**** как vue и angular
Согласен. Но степень уродства будет тем меньше, чем проще будет фреймворк, чем меньше новых принципов и концепций будет изначально в нем заложено. Но в то же время он будет полным. Без обид просто я считаю что mvc концепция уже изжила себя.
Ну раз они по Вашему все уродливые, может быть дело в архитектурном решении? И нам нужно что то концептуально новое? Я верю что можно построить безупречность. Дело в архитекторе
Ну раз они по Вашему все уродливые, может быть дело в архитектурном решении? И нам нужно что то концептуально новое? Я верю что можно построить безупречность. Дело в архитекторе
Вот Вы уже почти поняли мою идею. Но проблема в том что и sql и язык хранимых процедур и возможности меняются от СУБД к СУБД. И хоть и sql достаточно мощен чтобы вернуть из базы все в нужном виде, постобработка и вычисления иногда все же нужны.
Поэтому первое — нужен единый sql синтаксический сахар (сделаем язык общим для всех СУБД и заодно упростим его)
Второе — придумаем поддержку постобработчиков.
Приведу простой пример (отдалённый от жизни): вывести 10 последних зарегистрированных админа, если они зарегились в одном месяце:
Скрипт будет такой:
@lastTenAdmins = select from users
id.desc,
name
join user_group
join groups
name
where name = 'admin'
limit 10;
%regInSameMonth @lastTenAdmins;
Функция regInSameMonth в моем случае уже написана на php которая принимает результат выполнения запроса @lastTenAdmins.
Ни во что. Я хочу вообще избавиться от backend составляющей в ходе разработки. И от всех backend фрейморков как следствие. Использовать только frontend фреймворк, а в случае где необходимо использовать базу данных обращаться к ней напрямую, заставляя все необходимые данные отдавать уже в нужной структуре во фронтенд. Для этого создать какой нибудь язык типа suql который будет общим для всех СУБД. Который не просто облегчал синтаксис sql а и мог его расширить
Ваш сарказм понятен. Я действительно описал так, что можно так подумать. Но я топлю за то чтобы на backend стороне больше ответственности возложить на базу данных (логика и тд). Вы скажете что не разумно, так как СУБД может меняться. Тогда сделать по принципу как сделали в react native, где код компилится под определённую платформу. Собственно все дело в моем почёте к react, и то что он не похож на это однотипное г**** как vue и angular
Согласен. Но степень уродства будет тем меньше, чем проще будет фреймворк, чем меньше новых принципов и концепций будет изначально в нем заложено. Но в то же время он будет полным. Без обид просто я считаю что mvc концепция уже изжила себя.
Ну раз они по Вашему все уродливые, может быть дело в архитектурном решении? И нам нужно что то концептуально новое? Я верю что можно построить безупречность. Дело в архитекторе
Ну раз они по Вашему все уродливые, может быть дело в архитектурном решении? И нам нужно что то концептуально новое? Я верю что можно построить безупречность. Дело в архитекторе