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

Question

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

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

Звучит ли это для вас? Любой опыт, советы или мнения к этой идее?

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

Answer 1

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

Answer 2

Это не жизнеспособная идея, на мой взгляд. Есть ряд причин для этого.

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

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

Answer 3

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

Answer 4

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

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

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

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

Answer 5

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

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

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

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

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

Answer 6

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

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

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

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

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

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

Answer 7

Вы можете найти хороший обзор по анализу производительности приложения веб здесь: 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/