форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[ Отслеживать ]

"OpenNews: Архитектура 'тонкий сервер' с  обработкой данных н..."

Сообщение от opennews on 27-Фев-08, 21:30

"Тонкий сервер (http://abava.blogspot.com/2008/02/blog-post_27.html)" -  архитектура "тонкий сервер", когда логика обработки данных переносится на плечи клиента. URL: http://abava.blogspot.com/2008/02/blog-post_27.html Новость: http://www.opennet.me/opennews/art.shtml?num=14444

Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Архитектура 'тонкий сервер' с  обработкой данных на стороне ..."

Сообщение от leonid.ko on 27-Фев-08, 21:30

>- за сервером остается только следующий функционал: >a) безопасность >б) бизнес-логика >в) проксирование запросов к другим ресурсам что то терзают смутные сомнения меня по поводу пункта а)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Архитектура 'тонкий сервер' с  обработкой данных на стороне ..."

Сообщение от andruffka (ok) on 27-Фев-08, 22:12

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "Архитектура 'тонкий сервер' с  обработкой данных на стороне ..."
	Сообщение от Денис (??) on 28-Фев-08, 10:00
	>Чем больше кода на стороне клиента и чем разношерстнее эти клиенты, вы оcновное в этом подходе не поняли - код не загружается отдельно клиентом. Он получает его с веб-страницы. Как он может быть разношерстным? И правится (в случае необходимости) он опять таки в одном месте - на сервере
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Архитектура 'тонкий сервер' с  обработкой данных на стороне ..."

Сообщение от Jet (??) on 27-Фев-08, 22:29

>Соответственно, одна из основных проблем в разработке "толстых" клиентов - как >заставить пользователя загрузить и обновить приложение, когда что-то в логике >поменялось, здесь не существует. Обработчик автоматически загружается в браузер >клиента, когда он заходит на веб-страницу. Цель вполне очевидна - разгрузить >сервер, сделать приложение более масштабируемым. Боже, какой бред.....

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Архитектура 'тонкий сервер' с  обработкой данных на стороне ..."

Сообщение от Алекс (??) on 28-Фев-08, 06:21

Опус в стиле "пшик" в сторону распределённых вычислений. Почесать затылок и сказать себе честно - мы нихрена не понимаем в распределённых вычислениях или понимаем но нихрена никому не раскажем.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "Архитектура 'тонкий сервер' с  обработкой данных на стороне ..."
	Сообщение от Денис (??) on 28-Фев-08, 10:05
	>Опус в стиле "пшик" в сторону распределённых вычислений. Почесать затылок и сказать >себе честно - мы нихрена не понимаем в распределённых вычислениях или >понимаем но нихрена никому не раскажем. нет, к распределенным вычислениям это отношения не имеет. Все централизованно, клиенты взаимодействуют только  сервером etc. По факту для веб-приложений - это просто систематизация шаблонов проектирования, привязанных к слову JSON. Это там правильно написано - ноги отсюда растут
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Архитектура 'тонкий сервер' с  обработкой данных на стороне ..."

Сообщение от Евгений (??) on 28-Фев-08, 12:53

Интересно, каким образом можно к ЭТОМУ прикрутить безопасность?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "Архитектура 'тонкий сервер' с  обработкой данных на стороне ..."
	Сообщение от uldus (ok) on 28-Фев-08, 12:59
	>Интересно, каким образом можно к ЭТОМУ прикрутить безопасность? Подразумевается, что сервер отдает только данные в JSON, а JavaScript клиента стоит страницу. Безопасность получается даже выше, за счет выноса логики построения интерфейса с сервера. В обычных условиях сервер вернул те же данные по томуже запросу, но в красивой обертке.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "Архитектура 'тонкий сервер' с  обработкой данных на стороне ..."
	Сообщение от Keeper (??) on 28-Фев-08, 14:36
	А что помешает клиенту сфабриковать подложный запрос (например, при помощи исправления полученных Java-скриптов) и отправить его на сервер?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "Архитектура 'тонкий сервер' с  обработкой данных на стороне ..."
	Сообщение от uldus (ok) on 28-Фев-08, 14:51
	>А что помешает клиенту сфабриковать подложный запрос (например, при помощи исправления полученных >Java-скриптов) и отправить его на сервер? Вы же не в базу напрямую лезете, а говорите "хочу новости" и вам отдают блок новостей, тольно не в HTML, а в JSON, то что не положено вам не отдадут, точно также как если бы логика была целиком на сервере.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "Архитектура 'тонкий сервер' с  обработкой данных на стороне ..."

Сообщение от Serg (??) on 28-Фев-08, 17:11

Сдается мне, получим проблемы децентрализации, от которых старались уйти долгие годы: 1. неоднозначность выполнения скрипта на клиенте, 2. возможность правки кода на клиенте: клиентская часть решает, какие пункты меню будут доступны? Это безопасность? 3. "не в базу напрямую" - это круто, Jumla тоже не напрямую в базу дает лезть, а всего лишь через параметры, можно отправить лекторов к milw0rm. 4. Кто в этом случае хранит обрабатываемые данные? Клиент? Очень защищенное от сбоев решение... 5. >>вы оcновное в этом подходе не поняли - код не загружается отдельно клиентом. Он получает его с веб-страницы. Нет слов. А веб страница где? не на клиенте? Я почему-то думал, что страница живет в клиентском браузере, который может интерпретировать этот код, как ему заблагорассудится. 6. На кой черт проксировать запросы к другим ресурсам? Если ресурс мертв, данные проксика не валидны, если жив - их чудное приложение на клиенте может и само обрабатывать список зеркал, например. 7. Какая бизнес-логика? Кто решает, что будет видеть клиент? сервер? На основе тех данных и параметров, которые я могу задать в отладчике жабаскрипта? А давайте вернемся к отоплению жилья углем - от него дым прикольный... :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "Архитектура 'тонкий сервер' с  обработкой данных на стороне ..."
	Сообщение от Nick (??) on 28-Фев-08, 21:20
	А я вот увидел рациональное зерно в статейке (кроме кеширования запросов к другим серваисам %) >Сдается мне, получим проблемы децентрализации, от которых старались уйти долгие годы: >1. неоднозначность выполнения скрипта на клиенте, если уж на то пошло - то даже в HTML'е нет полной однозначности среди отображения во всех браузерах. Так чем же JavaScript принципиально хуже? Хоть так хоть так пришлось бы затачивать клиент-код под определенный браузер. >2. возможность правки кода на клиенте: клиентская часть решает, какие пункты меню >будут доступны? Это безопасность? ессьно, клиент пусть решает что ему взбредет. Но правомерность его запросов будет определятся на сервере. Это - безопасность. >4. Кто в этом случае хранит обрабатываемые данные? Клиент? Очень защищенное от >сбоев решение... Данные путем запросов отправляюццо на сервер, а там уже - как тебе нравится. Так что да, защита от сбоев лишь в руках админа. >5. >>вы оcновное в этом подходе не поняли - код не загружается отдельно клиентом. Он получает его с веб-страницы. >Нет слов. А веб страница где? не на клиенте? Я почему-то думал, >что страница живет в клиентском браузере, который может интерпретировать этот код, >как ему заблагорассудится. криво заинтерпретирует - ниче не увидит. (как я говорил, в какой-то степени это справлдливо и для "чистого" HTML) Посему участки кода под разных клиентов должны подгружаццо по его же запросу в результате своих же желаний. Ну а данные сервак отправляет всем видам клиентом в одинаковом формате. >7. Какая бизнес-логика? Кто решает, что будет видеть клиент? сервер? >На основе тех данных и параметров, которые я могу задать в отладчике жабаскрипта? с теми данными, что пожаловал клиенту сервер - делай что угодно :) Это правомерно твои данные, которые выделенны тебе бизнес логикой. С помощью нужных (сам, опять-таки, решишь каких) жабоскриптов устроишь себе просмотр в любимом клиенте (броузере). И при желании - будешь слать новые запросы серверу (которые все также будут проверены той же бизнес-логикой). Все на месте. >А давайте вернемся к отоплению жилья углем - от него дым прикольный... >:) нанюхамшись такого классного дыма - прикольнее сравнивать зеленое с длинным...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Архитектура 'тонкий сервер' с  обработкой данных на стороне ..."
	Сообщение от andruffka (ok) on 28-Фев-08, 21:36
	Каша какая-то. Покажите мне "тонкий" клиент на хтмл но без java/javascript? А те что со скриптами автоматом к "толстым" приравниваются? Вот для меня "толстый" клиент, это например продукт ЕМЕ, может кто слышал о таком (компания Нестле такой точно юзала). Там есть сервер, но рулит не многим, транзакции, синхронизация, свой движок для бд, а копия данных все равно на стороне клиента есть(нужных ему и не нужных), которые он повредить может. А когда данные на стороне сервера, сервер ими распоряжается, а на стороне клиента только рендереинг и простейшие скрипты, то какой же он "толстый".
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "Архитектура 'тонкий сервер' с  обработкой данных на стороне ..."
	Сообщение от Nick (??) on 28-Фев-08, 22:04
	>Каша какая-то. Покажите мне "тонкий" клиент на хтмл но без java/javascript? А >те что со скриптами автоматом к "толстым" приравниваются? читай сабж. Речь о "тонком" сервере, а не о "толстом" клиенте. Не нужно тут в поломанный телефон играть... >Вот для меня "толстый" клиент, это например продукт ЕМЕ, может кто слышал >о таком (компания Нестле такой точно юзала). Там есть сервер, но >рулит не многим, транзакции, синхронизация, свой движок для бд, а копия >данных все равно на стороне клиента есть(нужных ему и не нужных), >которые он повредить может. А когда данные на стороне сервера, сервер >ими распоряжается, а на стороне клиента только рендереинг и простейшие скрипты, >то какой же он "толстый". Ну, сам придумал что тема о "толстом" клиенте - и понесло... Не было об этом разговора.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	15. "Архитектура 'тонкий сервер' с  обработкой данных на стороне ..."
	Сообщение от admin (??) on 29-Фев-08, 00:21
	так бреттодо или бреддото?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "Архитектура 'тонкий сервер' с  обработкой данных на стороне ..."
	Сообщение от andruffka (ok) on 29-Фев-08, 00:31
	>Ну, сам придумал что тема о "толстом" клиенте - и понесло... > >Не было об этом разговора. А что, связка "тонкий" клиент и "тонкий" сервер может работать?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	17. "Архитектура 'тонкий сервер' с  обработкой данных на стороне ..."
	Сообщение от Nick (??) on 29-Фев-08, 03:58
	>А что, связка "тонкий" клиент и "тонкий" сервер может работать? напиши статейко и проанализируй это. Какие-то глупости пошли уже не по существу
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]