Комментарии 17
Как по мне, то database-centric решения очень нишевые, будущее вижу в event-based распределенных сетях, почти одноранговых, где часть нод берут на себя роль глобальных координаторов и "числодробилок". К событиям, похоже, можно свести и все остальные варианты в рамках, как говорится, "современной элементной базы", разница лишь в том, какие части распределенного приложения будут эмитировать события, а какие слушать и обрабатывать, насколько высоко в иерархии архитектурных сущностей отдельных процессов будут подниматься в виде каких-то абстрактных событий такие реальные события как приход пакета по сети или совершения пользователем действия типа нажатия клавишы.
На самом деле при повседневной текучке задач не сильно успеваешь задуматься куда мы идем.
Интересно разнести то что мы видим и используем в жизни в такую систему.
№0 Data files
Любимые всеми таблички Excel
№1 File-server
Ранее были очень популярные MS Access, FoxPro — базы данных интегрированные в приложение. Можно сказать что это движок базы данных с интерфейсом вшытым в нее.
№2 Local DB
В этом сегменте прошло мое отрочество — BDE и иже с ним.
№3 Client-Server
Большинство старых бизнес приложений, всё работающее в связке с MS SQL. Собственно большинство приложений работающих с локальной базой при росте количества пользователей мигрировали в этот режим работы.
№4 Three-tier
Большинство современных бизнес приложений (это в том числе и 1С и всевозможные клиенты к разнообразным промышеленным системам). Это просто колосальный по обьемам пулл приложений, обслуживающих заводы, общепит, производства, трубопроводы...
№5 Web-client
тут живет большая часть вэба — всевозможные php с wordpress (с колосальной долей сайтов в интернете)
№6 Web 2.0
мир открытый для меня первыми версиями gmail, с jquery и вереницами ajax запросов. Все сайты из №5 которые научились взаимодействовать с пользователями. Те же форумы, трекеры.
№7 SPA/WebApp
тут мы живем сейчас, Angular 2, React. Весьма уютное место на самом деле.
№8 PWA & Mobile
Сюда мы стремися попасть, добавляя PouchDB, FireBase etc.
Database-centric P2P Network — нечто похожее предсавляет из себя Эфириум с его смарт-контрактами
Попытался «натянуть» варианты #A, #B, #C and #D на ERP системы (ими занимаюсь) — не получилось.
Все варианты не полностью соответствуют задачам.
Больше всего сомнений в месте, где надо располагать логику. Если её писать и на клиенте и на сервере — очень быстро начинаются большие проблемы. В варианте #D вся логика на сервере, но зачем в ERP Peer-to-Peer — не понятно. В остальных вариантах логика и там и там и это может создать сложности.
Хотя если сделать вариант с «синхронизацией» части логики между сервером и клиентом — это может быть интересно. Описываешь всю логику на сервере, но часть из нее (например, первичная проверка данных) автоматом переносится в клиентское приложение и выполняется там…
С локальными DB тоже много вопросов. Выгрузить на клиента тот же справочник номенклатуры, если там сотни тысяч позиций — сомнительный вариант. Выгрузить частично — но тогда что именно выгружать и усложняется логика работы со справочниками.
Можно локально хранить данные об открытом / редактируемом документе, но это обычно небольшой кусок данных, и не очень понятно, насколько хранение таких данных поможет…
Вычисления на клиенте — возможно. Но точно не в самом клиентском приложении, а что то вроде распределенной вычислительной среды вполне можно использовать. Но в ERP потребность в таких вычислениях не очень часто встречается, и при этом обычно надо обрабатывать большие объемы данных — забьется канал.
Вообще, конечно, для ERP лучше разделить логику, что и предложено в «Hybrid Application». С разной пропорцией можно выделить:
— Логику модели (она запускается и на клиенте и на сервере, там, где работает модель)
— Логику бизнес-процессов (которую для ERP удобнее реализовывать на сервере)
— Логику интерфейса (которая запускается только на клиенте и абстрагирована от прочей логики)
И эти три вещи не можно так построить, что они не будут пересекаться и «знать» друг о друге.
Например, описали логику проверки корректности вводимых данных в интерфейсной форме (ведь при ошибке надо выдать пользователю предупреждение — значит логика интерфейса). Потом, например, реализуем загрузку тех же данных в пакетном режиме и тоже пишем ту же логику проверок. И после нескольких модификаций наборы правил проверки не полностью совпадают, и у нас труднодиагностируемый глюк в данных…
Причина в том, что логика может быть достаточно сложной. Например, было простое предупреждение, что заказ нельзя отгрузить, так как у клиента недостаточно кредитного лимита. Бралась текущая задолженность, к ней прибавлялась сумма заказа и результат сравнивался с кредитным лимитом. Если меньше или равен — то можно отгружать, если больше кредитного лимита — нельзя. Потом появилась идея для некоторых товаров (которые надо распродать) не учитывать их стоимость при расчете кредитного лимита. И правило должно было выглядеть так: если у клиента кредитный лимит больше нуля и нет просроченной задолженности, то сравниваем с кредитным лимитом только не распродажные товары, а распродажные товары из текущего заказа и предыдущих заказов в сравнении не участвуют. Это тоже можно описать функцией, но это намного более сложная функция получалась… И вообще такую проверку наверно надо не на уровне интерфейса делать, а на сервере. Но в первом варианте все было просто и легко реализовывалось на уровне интерфейса.
Если вы можете привести примеры систем, где удалось удачно реализовать описываемое вами разделение логики — укажите ссылку. Было бы интересно почитать.
И возможно стоит чуть подробнее описать «Hybrid Application». В таком виде, как сейчас, не совсем понятно, что скрывается за некоторыми терминами. Например, чем три вида логики друг от друга отличаются.
На шагах с #0 по #4 автор пытается рассказать про структуру бекенда, после чего внезапно перескакивает на фронтенд. По итогу нас ждет невнятная попытка все это обобщить, нелепая, как и весь js - автор будто бы пытается сложить число со строкой. Сверху все засыпано толстым слоем терминов, вероятно, для маскировки.
Эволюция приложений или куда мы идем