Вопрос об архитектуре корпоративного веб-приложения - PullRequest
0 голосов
/ 16 апреля 2011

Мне интересно, можно ли было бы разработать веб-приложение корпоративного уровня без использования стандартной структуры MVC и сервера приложений, перенося бизнес-логику и данные сеанса в Javascript клиентского размера и заставив его говорить? непосредственно к сервисам REST data ... может быть, мы могли бы использовать уровень авторизации / аутентификации и второй уровень валидации, расположенный поверх сервисов данных. Все эти сервисы работают по стандартным методам HTTP, поддерживают настраиваемую регистрацию и мониторинг, а параметры содержимого или запроса содержатся в теле запроса / ответа HTTP. Статический HTML и Javascript подаются в браузер, а остальное выполняется функциями Javascript, связанными с авторизацией / аутентификацией, проверкой подлинности на основе HTTP, а затем со службами данных. Как вы думаете, такая архитектура могла бы удовлетворить требования веб-приложений уровня предприятия?

1 Ответ

0 голосов
/ 17 апреля 2011

Это возможно, но вряд ли;Какие драйверы предлагают эту архитектуру для вас?Это просто быть другим или есть какие-то конкретные аспекты, которые лучше всего решать?

, передавая бизнес-логику и данные сеанса в клиентский Javascript и заставляя его напрямую взаимодействовать со службами данных REST

В теории вы все равно сможете иметь подходящее многоуровневое решение (сценарий Business Logic (BL) или сценарий, ориентированный на пользовательский интерфейс), но на практике это будет грязно;и вы потеряете способность физически разделить его на несколько уровней.Это может «укусить» вас в любом количестве мест в жизни системы.

Системы уровня «предприятия» редко бывают маленькими, я не хочу думать, сколько логики вам придется посылать по проводам.для поддержки определенного действия / процесса.

Помещение всех BL в язык сценариев связывает вас с этой платформой, и платформы со временем меняются.Плохая вещь в сценариях заключается в том, что, хотя они в некоторой степени стабильны, я бы предположил, что они более подвержены изменениям, чем серверные платформы, такие как Java или .Net.В корпоративном сценарии серверы будут иметь очень жесткий контроль изменений и пути обновления, намеченные для них - где браузеры гораздо более открыты для регулярных изменений.

Существует проблема совместимости - если только вы не привязаны к конкретному браузеру (на уровне версии), гарантировать согласованное поведение будет сложнее и, вероятно, потребуется больше усилий для разработки.Допустим, вы успешно доставили решение;Что вы делаете, когда бизнес хочет воспользоваться преимуществами мобильных компьютеров - скажем, iPad?Единственным вариантом будет браузер - вы не сможете воспользоваться какими-либо нативными преимуществами платформы.«Интернет и браузеры» могут показаться, что они будут существовать вечно, но тогда я предполагаю, что именно так говорили мейнфреймы в то время.Решение, ориентированное на сервер, даст вам больше жизни при меньших затратах.

Персонал будет проблемой - вам понадобятся очень сильные разработчики на JavaScript и на стороне сервера.

Безопасность: наличие вашегоосновной BL на клиенте, где гораздо более незащищенные звуки очень опасны.

РЕДАКТИРОВАТЬ:

Веб-приложения можно сеять по многим причинам - не многие из которых являются причинойдостаточно поставить все свой BL в JavaScript на клиенте.Создание приложений для повышения производительности - это отдельная область усилий. Я предлагаю вам поближе познакомиться с архитектурой и реализацией для повышения производительности, прежде чем полностью списать n-уровневые веб-приложения:)

Что касается сохранения ваших слоевразделены: есть разные способы сделать это, но все сводится к абстракции - и правильнее - помнить о хороших принципах дизайна;если вы не слышали о SOLID , это было бы хорошим началом.С точки зрения реализации начните читать с Deverdency Inversion (FYI - самореклама, мои статьи и сфокусированы на .Net, но у вас также не должно быть проблем с отслеживанием на основе Java).

...