Вопросы по архитектуре СПА

@ Сергей - я думаю, что это слишком широкий вопрос для StackOverflow. ТАК. не дискуссионный форум; это место, где можно найти конкретные ответы. Так что, хотя ваши вопросы потенциально верны, я не думаю, что вам следует возлагать большие надежды на глубокие содержательные ответы здесь.

Могу я добавить, как можно дружелюбнее, что ваши огульные, ничем не подкрепленные и негативные заявления выставляют вас троллем. Ты не тролль Сергей?

На случай, если вы на самом деле искренне обеспокоены, я предлагаю несколько быстрых ответов, особенно в том, что касается Бриза.

1. Авторизация. В Web API вы можете авторизоваться на уровне метода. Базовый класс ApiController имеет свойство User, которое возвращает значение IPrincipal. Таким образом, независимо от того, есть ли у вас один контроллер или несколько (и в Breeze их может быть много, если хотите), степень детализации находится на уровне метода, а не только на уровне класса.

2. Управление памятью. Разработчики настольных компьютеров годами справлялись с этой проблемой. У вас может возникнуть некоторое удивление, если вы всегда разрабатывали традиционные веб-приложения, в которых время жизни процессов невелико. Но длительные процессы не являются чем-то новым для тех из нас, кто создавал большие приложения на настольных технологиях, таких как WinForms, WPF и Silverlight. Проблемы и решения почти одинаковы в мире HTML и JavaScript.

3. Слои на серверной части. Вы слишком долго смотрели демоверсии. Да, большинство демонстраций сбрасывают все в один проект, работающий на одном сервере. Мы предполагаем, что вы знаете, как реорганизовать сервер, чтобы он соответствовал требованиям масштабирования, производительности и безопасности для вашей среды. Наши демонстрации в основном касаются разработки SPA-интерфейса. Мы коснемся границы службы, чтобы показать, как данные проходят через API службы, через ORM и далее в базу данных. Мы сочли достаточным идентифицировать эти отдельные слои и оставить читателю в качестве упражнения сравнительно тривиальный вопрос перемещения этих слоев на разные уровни. Возможно, однажды нам придется вернуться к этому предположению. Но кто-нибудь всерьез полагает, что существуют серьезные препятствия для распределения уровней/обязанностей между серверными уровнями? Действительно? Как что?

4. Ненавязчивая проверка. Когда большинство людей начинают использовать слово «ненавязчивый» в связи с HTML, они обычно подчеркивают, что JavaScript не должен использоваться в HTML. Возможно, это то, что вы тоже имеете в виду, и в этом случае разработчики SPA повсюду согласны ... и именно поэтому существует множество доступных библиотек «ненавязчивой проверки». На ум приходят проверка HTML 5, проверка jQuery и проверка Knockout. Все они находятся в наборе инструментов разработчика SPA, и ни один из них «не требует от разработчиков использования частичных представлений и контроллеров MVC». Почему у вас сложилось впечатление, что SPA потребуются любые ресурсы на стороне сервера для реализации проверки с помощью HTML-разметки без JavaScript?

5. Идентификаторы как угроза безопасности. Действительно? Это подделка. Значение ключа представляет собой не большую угрозу безопасности, чем любое другое значение данных. Миллионы приложений — не только SPA — передают значения ключей клиенту как в URL-адресе, так и в теле. Это стандарт в REST API. Это стандарт в ODATA. И вы хотите отмахнуться от них всех, заявив, что они «нацелены на области с небольшими требованиями к безопасности и небольшим набором функций»? Удачи с этим. Я думаю, что вам придется поступить лучше, чем основывать свое дело на ссылке на весь веб-сайт относительно малоизвестной организации.

Я создал несколько приложений SPA, от маленьких до больших (более 100 сценариев и представлений). Только у горстки из них все представления были доступны для публики. Остальные прошли через строгую пропускную структуру. Было так просто вернуть 401 несанкционированный сервер, а клиент просто обработал 401, чтобы перенаправить его на экран входа в систему. Мистер Уорд и мистер Папа все исправили. Выйдите из демо-режима и попытайтесь найти решения проблем, с которыми вы сталкиваетесь. Я просмотрел SPA Джона Папы во множественном числе, просмотрел множество статей и приложений о Breeze, и я должен сказать вам, что ни одно из моих приложений не использует Breeze для выполнения запросов со стороны клиента, потому что ВАМ ЭТО НЕ НУЖНО!!

Более того, я лишь расширил то, чему научился, и придумал свой способ решения проблем. Это не ответ на ваши вопросы, но я могу дать только краткий комментарий. Ни одна техника не идеальна, и нет ОДНОГО способа сделать все. Моя серверная часть заблокирована там, где она должна быть заблокирована, мои маршруты на стороне клиента заблокированы (если используете durandal, взгляните на guardRoute), мои скрипты минимизированы, а мои изображения спрайты (если есть такое слово, как это). В общем, СПА — отличная техника, нужно находить решения причудам!