Мне интересно, можно ли разработать веб-приложение корпоративного уровня без использования стандартной структуры MVC и сервера приложений, перенося бизнес-логику / логику потока и данные сеанса в Javascript размера клиента и заставляя его разговаривать с данными REST сервисы напрямую ... возможно, мы могли бы использовать уровень авторизации / аутентификации и второй уровень проверки, расположенный поверх сервисов данных. Все эти службы работают со стандартными методами HTTP, поддерживают настраиваемое ведение журнала и мониторинг, а параметры содержимого или запроса содержатся в теле запроса / ответа HTTP. Статический HTML и Javascript обслуживаются браузером, а остальное выполняется функциями Javascript, обращающимися к HTTP-авторизации / аутентификации, проверке и затем службам данных. Как вы думаете, может ли такая архитектура удовлетворить требования веб-приложений корпоративного уровня?
Вопрос об архитектуре корпоративного веб-приложения
Ответы (1)
Это возможно, но маловероятно; какие драйверы предлагают вам эту архитектуру? Просто чтобы быть по-другому, или есть какие-то конкретные аспекты, которые лучше всего решаются?
передавая бизнес-логику / логику потока и данные сеанса на клиентский Javascript и заставляя его напрямую взаимодействовать со службами данных REST
В теории у вас все еще будет возможность иметь подходящее многоуровневое решение (сценарий Business Logic (BL) против сценария, ориентированного на пользовательский интерфейс), но с практической точки зрения это будет беспорядочно; и вы потеряете возможность физически разделить его на разные уровни. Это может «укусить» вас в любом количестве мест в жизни системы.
Системы уровня «Enterprise» редко бывают маленькими, мне неприятно думать, сколько логики вам придется отправлять по сети для поддержки данного действия / процесса.
Включение всех BL в язык сценариев привязывает вас к этой платформе, и платформы меняются со временем. Плохая вещь в сценариях заключается в том, что, хотя они в определенной степени стабильны, я бы предположил, что они более подвержены изменениям, чем серверные платформы, такие как Java или .Net. В корпоративном сценарии серверы будут иметь очень жесткий контроль над изменениями, и для них будут намечены пути обновления, тогда как браузеры гораздо более открыты для регулярных изменений.
Есть проблема совместимости - если вы не привязаны к конкретному браузеру (на уровне версии), гарантировать согласованное поведение будет сложнее и, вероятно, потребуются дополнительные усилия при разработке. Допустим, вы успешно доставили решение; что вы делаете, когда бизнес хочет воспользоваться преимуществами мобильных вычислений - скажем, iPad? Единственным вариантом будет браузер - вы не сможете воспользоваться ни одним из преимуществ платформы. Может показаться, что «Интернет и браузеры» будут существовать вечно, но я предполагаю, что это то, что в то время говорили люди из MainFrame. Решение, ориентированное на сервер, даст вам больше жизни при меньших затратах.
Проблема будет с кадрами - вам понадобятся очень сильные разработчики на JavaScript и на стороне сервера.
Безопасность: размещение вашего основного BL на клиенте, где он гораздо более уязвим, звучит очень опасно.
РЕДАКТИРОВАТЬ:
Веб-приложения можно сеять по многим причинам, не многие из которых являются достаточной причиной, чтобы поместить все ваши BL в JavaScript на клиенте. Создание приложений для повышения производительности - это целая область усилий сама по себе - я предлагаю вам поближе познакомиться с архитектурой и реализацией для повышения производительности, прежде чем вы вообще откажетесь от многоуровневых веб-приложений :)
Что касается разделения слоев: есть разные способы сделать это, но все сводится к абстракции, а точнее - к сохранению хороших принципов дизайна; если вы не слышали о SOLID, это было бы хорошее место для Начало. Что касается реализации, начните читать Инверсия зависимостей (к вашему сведению - самореклама, статьи мои и ориентированы на .Net, но у вас не должно возникнуть проблем с отслеживанием и тех, которые основаны на Java).
