Веб-приложения: логика домена на стороне клиента

Question

Мы видим все больше и больше работы для веб-приложений на стороне клиента. Манипуляции с пользовательским интерфейсом, предварительная проверка ввода (конечно, не в качестве последнего средства проверки), виджеты, эффекты и т. Д. И т. Д.

Что, если кто-то решит разместить доменную логику на стороне клиента, написанную на Javascript / GWT / что-нибудь еще? Сервер просто обеспечивает инфраструктуру базы данных.

Это звучит для вас жизнеспособно? Есть опыт, совет или мнение по этой идее?

Edit: Если вы возитесь, вы поймете, что можно писать целые приложений без единой строки php / python / java / чем угодно.

Answer 1

Я с уважением не согласен с другими постерами здесь. Фактически, я реализовал именно такую ​​ настольную игру с скрэбблом , используя почти полностью логику на стороне клиента. На самом деле, я бы хотел сделать много вещей, чтобы сделать его еще более интенсивным на стороне клиента. GMail проделывает огромную работу на стороне клиента.

Тем не менее, есть некоторые вещи, которыми нужно управлять на стороне подачи по практическим причинам. Например, сервер должен предоставить пользователю несколько плиток, а затем пользователь может сообщить серверу, куда он поместил эти плитки, и сервер должен проверить, что эти слоты пусты, потому что сервер никогда не может полностью доверять клиенту (клиент всегда может быть взломан). если не через скрипт, то перехватывая HTTP-трафик и изменяя его).

Существует множество технологий, в том числе ADO.NET Data Services для предоставления операций CRUD в БД через интерфейс RESTful, и CouchDB для хранения / управления объектами данных напрямую через JavaScript. Кроме того, богатые клиентские библиотеки, такие как jQuery или Moo Tools, действительно заставляют клиента делать все больше и больше.

И если вы подумаете об этом, Flash - это все, что связано с пользовательским интерфейсом и взаимодействием на стороне клиента. Некоторые из приложений Adobe Flex просто потрясающие. Недавно я использовал один для Google Analytics, который отображает графики, разворот и все это на стороне клиента. Сервер просто обслуживает данные. Несмотря на это, Google Gears и Firefox (3.2, я полагаю?) Теперь предоставляют хранилище на стороне клиента, что делает сценарии отключенных приложений еще более интересными.

Answer 2

С обзором производительности веб-приложения вы можете ознакомиться здесь: http://www.websiteoptimization.com/speed/tweak/psychology-web-performance/

Короче говоря, современные веб-приложения борются за повышение производительности на 100 мс. На таком коротком промежутке времени проблема уже связана с задержкой http. Таким образом, большая часть логики перемещается на клиентскую сторону только для того, чтобы уменьшить количество http-вызовов при взаимодействии с пользователем.

Существует ряд доступных и разрабатываемых платформ, которые помогают в создании сложного клиентского кода. Для начала: jQuery (UI), Dojo, MooTools, Prototype и т. Д. - это более общие рамки и подходят для любой логики на стороне клиента.

Точнее:

• Backbone.js - Реализация ядра MVC в простом javascript.
• jQuery.templates, jsViews, jsRender - рендеринг на стороне клиента и привязка данных
• другие

Здесь представлен полный обзор различных фреймворков http://codebrief.com/2012/01/the-top-10-javascript-mvc-frameworks-reviewed/

Answer 3

Для любого общедоступного (и непубличного) веб-приложения это лишь вопрос времени, когда кто-то попытается проверить вашу защиту. Проверка JavaScript будет первой. Поскольку вы можете просто отключить его в браузере или даже отключить / включить его во время работы с вашим приложением для достижения желаемого эффекта.

На самом деле у вас должно быть три уровня проверки.

1. Проверка пользовательского интерфейса (необязательно): первая проверка пользовательского ввода. Быстрый ответ без обращения к серверу -> пользователь счастлив + ваши серверы рады, что вы уже можете освободить их от некоторого количества недействительных запросов.

2. Проверка на стороне сервера (обязательно). Здесь снова проходит вся эта проверка + правила бизнес-логики. Скорее всего, вам придется получить доступ к некоторым стандартным или сторонним библиотекам, чтобы проверить / проверить / сделать все, что вам нужно. Здесь вы достигаете целостности данных на уровне BL.

3. Проверка на уровне базы данных (очень желательно). Последний периметр обороны. Обеспечение целостности данных за счет использования внешнего ключа / уникального ключа / и т. Д. ограничения + защита на уровне транзакций от нескольких параллельных запросов, внезапно разрушающих вашу целостность BL-уровня.

Так и должно быть, если вы хотите сделать это правильно.

Answer 4

Зависит от приложения и от того, как вы хотите его использовать и повторно использовать код.

Клиентский JavaScript действительно специфичен для веб-браузеров.

Доменные объекты и сущности могут быть повторно использованы в других приложениях (рабочие столы, веб-службы и т. Д.)

Не говоря уже о том, когда и если ваше приложение становится все больше и больше, время загрузки будет увеличиваться и увеличиваться.

И, конечно же, любой может скопировать, вставить ваш код и быстро клонировать ваше приложение.

Answer 5

Я думаю, что это не будет жизнеспособным, по крайней мере, если вы стремитесь к последовательности и скорости. Внедрение большого количества логики, скажем, в Javascript повлечет за собой большую работу для браузера, что означает SLOW-клиент. Кроме того, не забывайте, что у всех браузеров есть свои маленькие причуды.

Answer 6

Это не жизнеспособная идея, по моему мнению. Для этого есть ряд причин.

1. Что произойдет, если у пользователя нет этих возможностей на стороне клиента, потому что у него более старый браузер? Сайт, скорее всего, не будет работать.
2. Всегда, всегда выполняйте все те же проверки на сервере для проверки ввода и проверки правил, что и на клиенте. В противном случае это приведет к серьезным проблемам с безопасностью на вашем сайте. Пользователи могут обойти все проверки javascript и делать с вашей базой все, что захотят.

В целом, хотя код на стороне клиента действительно удобен для предоставления пользователям больше ощущения приложения, чем ощущения веб-страницы, для обеспечения безопасности и доступности веб-сайта необходимо реализовать оба метода.

Answer 7

Все это хорошо, но помните, что если кто-то отключит javascript, вам нужно будет обработать это и проверить ввод на сервере, прежде чем ваши пользователи будут связываться с вашей базой данных. Таким образом, вы можете поместить все, что хотите, на стороне клиента, но вам также необходимо проверить это на стороне сервера.