Толстый и тонкий
Вот нас тут спрашивают про то, что такое "тонкий клиент", и чем он отличается от "толстого клиента". На самом деле, конечно, не спрашивают, а наоборот, пытаются пудрить мозги, но это не суть. Ясность необходимо внести в любом случае. Так вот.
"Толстый клиент" и "тонкий клиент" - это разновидности архитектурных решений при разработке веб-приложений. А что такое "архитектура ПО"? Ну, я уже давал определение с пояснениями, повторяться нет смысла. Давайте лучше рассмотрим, что это означает в конкретном контексте - и получим, во-первых, ясность с понятиями худобы клиента, а во-вторых, иллюстрацию к общему посту об архитектуре, что тоже немаловажно.
Итак. Одной из проблем современного программирования является то, что все пытаются быть сильно умными. Я не имею в виду программистов (как раз тут-то бывают и проблемки...). Но ведь дошло до того, что каждый браузер пытается из себя изображать интеллектуальную единицу. В результате возникает возможность, а одновременно с ней и необходимость выбора, где выполнять функции, которые могут быть выполнены и на клиенте, и на сервере. Ну вот, например, где создавать структуру таблицы, на сервере тегом table, или на клиенте через css? Или есть список - где его сортировать, при запросе к базе на сервере или прямо в браузере? Ну, и множество других мелких вопросиков, из разрешения которых программирование в значительной мере и состоит.
В ситуации, когда на клиентской стороне не браузер, а какое-то наше собственное ПО, проблема не только не отменяется, а даже обостряется.
Существуют три очевидные стратегии принятия решений в этих случаях. Самая распространенная называется "как бог на душу положит", и суть которой ясна из ее названия. На самом деле применение этой "технологии" означает, что архитектурного решения этого вопроса просто нет. Что вовсе не мешает вести непрерывные "исследовательские" разборки о том, какая же у нас архитектура. Все это хотя и жизненно, но совсем не интересно, ибо надоело - дальше некуда.
Ну, и собственно, два других напрашивающихся варианта. Можно договориться (или принять волевым решением, если найдется воля и решимость, во-первых принять на себя такое решение, а во-вторых, его до конца поддерживать), что выбор всегда делается в пользу обработки на сервере. Раз есть договоренность, то это уже элемент архитектуры, и вот именно он-то и называется "Тонкий клиент". Есть и противоположный выбор - все, что возможно, делаем в браузере на месте - это "Толстый клиент".
Какая из двух архитектур лучше - зависит от конкретного проекта. Тонкий клиент, в сравнении с толстым, меньше зависит от необходимости учета особенностей конкретных браузеров, но требует больших вычислительных мощностей на сервере. Насколько важен тот или иной фактор, нужно смотреть по конкретной ситуации. На самом деле, конечно, возможны и любые другие архитектурные решения, в которых правила выбора места обработки и не столь примитивны и не описываются квантором всеобщности. На то и архитектор! И дело, в конце концов, не в названии. Главное, чтобы архитектура действительно была и поддерживалась всеми участниками разработки. Мне кажется, это должно быть хотя бы теоретически ясно.
"Толстый клиент" и "тонкий клиент" - это разновидности архитектурных решений при разработке веб-приложений. А что такое "архитектура ПО"? Ну, я уже давал определение с пояснениями, повторяться нет смысла. Давайте лучше рассмотрим, что это означает в конкретном контексте - и получим, во-первых, ясность с понятиями худобы клиента, а во-вторых, иллюстрацию к общему посту об архитектуре, что тоже немаловажно.
Итак. Одной из проблем современного программирования является то, что все пытаются быть сильно умными. Я не имею в виду программистов (как раз тут-то бывают и проблемки...). Но ведь дошло до того, что каждый браузер пытается из себя изображать интеллектуальную единицу. В результате возникает возможность, а одновременно с ней и необходимость выбора, где выполнять функции, которые могут быть выполнены и на клиенте, и на сервере. Ну вот, например, где создавать структуру таблицы, на сервере тегом table, или на клиенте через css? Или есть список - где его сортировать, при запросе к базе на сервере или прямо в браузере? Ну, и множество других мелких вопросиков, из разрешения которых программирование в значительной мере и состоит.
В ситуации, когда на клиентской стороне не браузер, а какое-то наше собственное ПО, проблема не только не отменяется, а даже обостряется.
Существуют три очевидные стратегии принятия решений в этих случаях. Самая распространенная называется "как бог на душу положит", и суть которой ясна из ее названия. На самом деле применение этой "технологии" означает, что архитектурного решения этого вопроса просто нет. Что вовсе не мешает вести непрерывные "исследовательские" разборки о том, какая же у нас архитектура. Все это хотя и жизненно, но совсем не интересно, ибо надоело - дальше некуда.
Ну, и собственно, два других напрашивающихся варианта. Можно договориться (или принять волевым решением, если найдется воля и решимость, во-первых принять на себя такое решение, а во-вторых, его до конца поддерживать), что выбор всегда делается в пользу обработки на сервере. Раз есть договоренность, то это уже элемент архитектуры, и вот именно он-то и называется "Тонкий клиент". Есть и противоположный выбор - все, что возможно, делаем в браузере на месте - это "Толстый клиент".
Какая из двух архитектур лучше - зависит от конкретного проекта. Тонкий клиент, в сравнении с толстым, меньше зависит от необходимости учета особенностей конкретных браузеров, но требует больших вычислительных мощностей на сервере. Насколько важен тот или иной фактор, нужно смотреть по конкретной ситуации. На самом деле, конечно, возможны и любые другие архитектурные решения, в которых правила выбора места обработки и не столь примитивны и не описываются квантором всеобщности. На то и архитектор! И дело, в конце концов, не в названии. Главное, чтобы архитектура действительно была и поддерживалась всеми участниками разработки. Мне кажется, это должно быть хотя бы теоретически ясно.