Многие не осознают, что написав 1с82, селезневские сделали не шаг вперед, а шаг назад - к ассемблеру.
По сути, программист теперь должен вместо системы или компилятора оптимизировать код именно для трезвенки.
при этом если 1с работает в файловом режиме, все его усилия насмарку.

Вместо того, чтобы написать своё RDP, 1с придумало тонкого клиента и напрягла программистов, вам не кажется?

Мне кажется, что трехзвенка 1С82 - это шаг назад и хороший превращает инструмент RAD в УГ, которого много (Navision, Axapta и т.п.)

Вот так

Тонкий клиент рулит

Добавилась гибкость, но при этом добавилась возможность и ассемблировать при желании.

По названию темы подумал, что уже можно в тексте модуля делать вставки на ассемблере ). А по теме, главное, что на машинные коды не переводят 1Сников.

Не надо свое РДП, когда есть браузер.
Разделение серверного и клиентского функционала реализовано логично и красиво.

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

Управляемые формы прекрасны.
Просто они не терпят тупорылость и гамнокод.

(178) +100500 ИМХО, лучше и не скажешь.

ТС, пиши под толстого клиента и используй RDP, что мешает то?
По теме - сталкивался с некорректной работой локально подключаемого оборудования при работе через RDP: при режиме работы RDP в окне - сканер символы (не цифры) считывает нормально, при разворачивании на весь экран - меняет регистр символов, сисадмины победить не смогли...

Клюшечнику клюшечное

(309) разработка уф как раз и позволит не накрыться

3х звенка это безопасность, производительность, эффективность написания кода

(340) не понятно, зачем г-ну Нуралиеву пилить свое собственное бабло...

УФ - это не только для браузеров, это еще всякие интерфейсные вкусности типа динамич. списков; это исполнение тяж. кода на 64х сервере (хотя и до этого конечно можно было вызывать общ.модули на сервере, но тем не менее), это снижение трафика по локал.сети при грамотном проектировании конфы. Реально: давече одни тут хотели в иерархич. справочнике доп. иерархию по неск. реквизитам (с УФ легко).

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

Тонкий клиент позволяет не загружать сеть и клиентский комп не нужными данными и процессами.

Все ветку не читал.
По теме:
Похоже Гений просто сам не смог осилить 3х-звенку, но желает, чтобы программа была умней его и сама себя осилила.

1С предоставила инструмент. Кто не желает УФ и тонкий клиент, пользуется толстым.

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

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

Это однозначно будет круто :) вот тогда будет реальное разделение, а сейчас некий симбиоз...

И сейчас это частично есть, но для нормальной работы в таком режиме 1с нужно еще дофига сделать... Думаю в 9.0 будет именно такой подход!

Предложенная модель клиент-серверного взаимодействия над RDP имеет целый спектр преимуществ:
1. Программа работает в окружении клиентской машины. Следовательно, мы свободно использует механизмы клиентской ОС - открытие документов в других приложениях, использование генерируемых файлов в других приложениях, печать, переключение раскладок, хранение временных файлов. Может еще чего забыл из серьезно важного. Все это крайне важно, но было невозможно или проблематично в среде RDP. Отсюда и поползли такие извращения, вроде почтового клиента в 1С вместо связки с аутглюком, мышью и птицей.
2. Экономия трафика. К примеру, система ЭДО или просто хранение сканов сертификатов в базе. RDP подразумевает открытие и работа с файлом в Word именно в режиме терминального сеанса. То есть канал загружается любым моим движением мыши в Word. В режиме трезвенки (как web так и тонкий клиент) я получаю себе на клиент только сам файл, изменяю без обмена трафиком с сервером, и возвращаю опять же только файл без дополнительного трафика.
Работа в терминале с теми же файлами CAD систем или графикой была вообще невозможна - передача полноцветной картинки (32 бита цветность на WQXGA 2560?1440) не работала даже на 10 мегабит VPN. Тонкий клиент легко победил эту беду.
3. Надежность связи.
Клиент в правильной системе не обращается к серверу при каждом движении мышью. Некоторые вещи (например подгонка цен в накладной) вполне реализуется без единого обращения к серверу.
4. Оптимизация взаимодействия.
Часть функционала работает и на клиенте, и на сервере. Таким образом разработчик распределяет нагрузку клиент/сервер и оптимизирует количество и объем обращений к серверу.
5. Уход в "облака".
Все крики о призрачности облачных концепций разбиваются о тенденцию BYOD - принеси собственный девайс на работу. Менеджмент компаний хочет получать на свой iPad или Samsung Galaxy S3 договора и скидки на согласование, смотреть интерактивные отчеты, отслеживать динамику бизнес-процессов, вести общение в корпоративной сети. Все это сделать в удобном для пользователя виде на классическом клиенте без УФ в принципе не возможно.
Если 1С не будет это делать - ее выдавят более прогрессивные конкуренты сначала в среднем сегменте, а затем и ниже.

Сейчас почитаю ветку - может еще чего допишу.

проголосовать, кстати, забыл )

А что тут выбирать-то...

я попрогил в начале года УТ11 и понял что это круто. Хотя в прошлом году долго разгонялся.