izekia EmeryОставим в стороне технологию клиент-сервер. Мне кажется, ее использование упрощает жизнь разработчику, но усложняет жизнь пользователю (в смысле, мало комфорта для работы). Хотя фирма 1С и попыталась в восьмой версии своего продукта совместить несовместимое (интерфейс от файл-сервера, а доступ к данным от клиент-сервера, для чего ей пришлось ввести лишнее звено-посредник – сервер приложений)
Интересно причем здесь комфорт, и почему сервер приложения - это лишнее звено.
Уже по тому, что задается такой вопрос, видно типичное отношение разработчика к своей программе, мол, «мне с ней не работать». Да, простой «юзверь» неприхотлив, берет все что дают и, как правило, молчит в тряпочку. Я, к примеру, работаю на предприятии, где используются мои программы учета. И не разу не слышал замечаний по удобству работы. Однако мне самому иногда приходится садиться за свои программы, чтобы навести марафет, найти ошибки пользователя и так, по мелочам. Меня сильно раздражает, если где-то приходится делать лишние телодвижения, что-то не совсем удобно и т.п. И хотя никто не просит, стараюсь убирать явные ляпы. Но иногда приходится иметь дело с чужими программами учета. И если вижу наплевательское отношение разработчика к пользователю, то это вызывает массу комментариев в адрес автора сего произведения. Иногда автор искренне не понимает, чего ждут от него пользователи, многие вообще «тираны», мол, делай, как я сказал и не вякай. Даже если делать приходится дурную работу. Тем не менее, основная претензия к тому, что «мало комфорта» заключается в слабой функциональности программы. Особенно это касается «тонких» клиентов. Их легко делать, но с ними очень тяжело и неприятно работать. Фирма 1С, в «восьмерке» сделала «толстого» клиента, но через одно пикантное, не побоимся этого слова, «импозантное» место. Сервер приложений, как таковой, отнюдь не плох, но не в данном случае. В 8-ке он используется исключительно как посредник, а «зачем нам кузнец, кузнец нам не нужен». Его использование говорит о концептуальных ошибках архитектуры приложения, которая так любит делать фирма 1С, что и вызывает массу нареканий в ее адрес. Можно ведь спроектировать так программу, чтобы в ней вместо «трехзвенки» была «двухзвенка», что скажется только в сторону повышения производительности работы, без потери удобства интерфейса. Для этого надо только либо интерфейс организовать по технологии «клиент-сервер» (это не типично, но можно), либо технологию доступа к данным заменить на файл-серверную (как было в семерке). Однако говорить об этом фирме «1С» бесполезно, ребята просто зарабатывают деньги на лохах, которые любят понты, мол, программа крутая, полно всяких рюшечек, требуется мощнейшее компьютерное оборудование для работы. Видел даже в Интернете тестирование серверов с помощью 1С8.х, мол, сервер такой крутой, что поддерживает десяток – полтора клиентов на «восьмерке». Я не намерен критиковать 1С, их продукт 1С77 просто прелесть, хотя и его можно сделать лучше. В данном случае важнее понимать концептуальные вопросы программирования, чтобы не делать хотя бы явных глупостей.

Dima T EmeryОставим в стороне технологию клиент-сервер. Мне кажется, ее использование упрощает жизнь разработчику...)
Это только тебе так кажеться :) Файл-сервер писать как-раз гораздо проще. Относительно 1С77+MS-SQL - это не клиент-сервер, а полный изврат, т.к. MS-SQL тут используется как файл-сервер, для чего он абсолютно не приспособлен отчего и тормозит все жутко.)
Ну, вот, сместились акценты и спор пошел в другом русле. Я не утверждал, что 1С77, или даже его SQL-ная версия это клиент-сервер. 7-ка это типичный файл-сервер, даже если он использует SQL-сервер (как файл-сервер). Понятно, что 1cv7s.exe всего лишь использует другое хранилище (не dbf-файлы, а базу данных SQL-сервера) и ничего более. Правда, те, кто хочет, применяют внешние компоненты для прямого доступа к базе данных SQL-сервера и использования всех его преимуществ. Основная масса профессионалов так и делает, заметно повышая производительность стандартной sql-ной «семерки». Лично я пошел другим путем, использовал не SQL-сервер через внешние компоненты, а движок Visual FoxPro, v.8. (вместо «1C Database Engine for .DBF, .CDX» из dbeng32.dll) для dbf-версии 1С77. Для обмена данными на уровне интерфейса задействовал DDE-сервер из 1С77. Замеры показали повышение производительности в 15 раз. И уже знаю, как повысить производительность еще в несколько раз за счет программной оптимизации. Для моих целей этого вполне достаточно.

Клиент-сервером является «восьмерка», т.е. 1С8.х и то на стороне сервер-приложения – база данных MS SQL Server. А в цепи интерфейс – сервер-приложения (или везде при использовании встроенной базы данных 8-ки (типа mdb-файла)) это типичный файл-сервер, что действительно является извратом.

«Файл-сервер писать как-раз гораздо проще»? Интересно где, в 1С? Если там то, да. Там он уже написан за нас. Но у нас то речь идет прежде всего о С++, а тут «толстого» клиента писать значительно тяжелее, чем «тонкого». То же можно сказать, например, и про Access. Организовать в Си и Акцессе интерфейс на уровне 1С – запаритесь, а какую-нибудь простую перегружаемую форму, «общающуюся» через провайдера данных, например, с SQL-сервером, относительно несложно.

Dima TПравильно спроектированное клиент-серверное приложение в разы быстрее и аналогичного файл-сервера, т.к. основной выигрыш тут идет в том что при файл-сервере качаются все данные на клиента и клиент делает выборку, а при клиент-сервере выборка делается сервером и только ее результат дается клиенту, что значительно снижает объем трафика (это немаловажно даже при объеме базы несколько десятков Мб), да и выборка сервером делается быстрее, т.к. железо там помощнее и большая часть данных уже в памяти закэширована может быть.
Почти что цитата из учебника. В принципе с этим никто не спорит. Но следует понимать, что «клиент-сервер» имеет как достоинства, так и недостатки. Хорошо о них было сказано в статье «Блеск и нищета клиента-сервера», поищите в Интернете, название цитирую по памяти. Возьмем простую навигацию данных. Пользователю интересно просто просматривать большую базу данных «вааще». Файл-сервер дает полный доступ ко всей базе данных, которую юзер может целиком сортировать, модифицировать где угодно и как угодно. Клиент-сервер даст ему только часть базы, а для этого юзверь должен ввести что-то типа запроса, ну там выбрать конкретный параметр, ограничения и т.п. А если пользователь не знает что он хочет, и желает только посмотреть, что вообще есть в базе? А если юзер продвинутый и может явно сформулировать интересующий его запрос, но тонкий клиент не может его обработать? Что тогда? Мол, бери что дают, а не то, что хочешь? Понятно, что клиент-сервер задает жесткую схему отношений, что может быть хорошо для целей безопасности, но плохо для комфортной работы по произвольной навигации по базе данных. Кроме того, сложные, комплексные системы учета просто трудно организовать на уровне интерфейса в виде чистого клиент-сервера, он просто не будет покрывать всех потребностей системы да и желаний пользователей. Тут конечно можно спорить, и я видел (у друзей программистов) реализации серьезных программ учета в виде, скажем, перегружаемой формы Акцесса в связке с SQL-сервером. Но этот минималистский интерфейс, хотя и позволяет достигать результата, но меня, однако, не прикалывает. 1С77 в этом смысле молодец, они сфарганили прекрасный интерфейс в простом деловом стиле, а разработчик объектов-справочников там просто умница. Но, конечно, какая бочка меда без своей ложки дегтя? Слабым местом в семерке является ее самописный движок базы данных. Многих это приводит в ступор и заставляет метаться между VFP (Парус), Navision, Axapta, SAP, R/3, Oracle, Access+SQL и т.д. и т.п., даже для решения относительно несложных учетных задач. Хотя при наличии небольшого воображения, легко значительно повысить производительность «семерки». Моим решением для dbf-версии 1С77 была связка DDE + ядро VFP, причем не знаю случая, чтобы так делал кто-то еще, все обычно предпочитают sql-версию 1С77 в связке внешние компоненты + SQL Server.
Чтобы вернуться к теме С++, скажу в Си я планирую применять CListCtrl в виртуальном режиме, а поставщиком данных использовать RunTime Library VFP9, и базу данных в виде dbf-файлов (втором фундаментальном формате данных, после текстового *.txt). VFP можно использовать и как файл-сервер и как клиент-сервер. Виртуальный режим контрола SysListView32 (в MFC-обертке) это просто находка!
Что позволят легко организовать полноценный интерфейс (по типу 1С) на технологии клиент-сервер. Единственное ограничение это то, что CListCtrl (на базе SysListView32) искусственно ограничен 100 миллионами записей. Но думаю, если достигну такого количества записей в базе данных, то найду способ его преодолеть. Здесь VFP не принципиален, при масштабировании задачи можно будет напрямую подключаться к промышленным базам данных. Просто RunTime Library VFP9, поставляется Мелкософтом бесплатно, и достаточно хорош для моих целей.

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

Dima TСлучаи когда "тонкого клиента" кто-то пишет только потому что ему попробовать охота рассматривать не будем.
Тогда укажите пример реализации интерфейса «толстого» клиента (как в 1С) на базе чистого «клиент-сервера».

Dima T EmeryКстати, если не секрет, а как вы планируете организовать доступ к базам данных?
Немно плюсов связки 1С77+MS-SQL: есть такая компонента 1С++ …
Речь шла об использовании С++, а не 1С. В 1С77 я уже профессионально реализовался, достиг приличных результатов, на которых можно доехать до пенсии. Но мне интересно сделать свои учетные программы независимыми от 1С и лишенных некоторых его недостатков, которые нельзя устранить никакими внешними компонентами.

Dima TPS Прежде чем хаять клиент-серверные решения (тем более только по изучению оных в убогой реализации 1С77) рекомендую для начала освоить эту технологию и понять все ее плюсы и возможно использовать из тойже 1С.
Плюсы клиент-серверных решений я знаю, и минусы тоже. Вы же знаете минусы 1С77, но не знаете ее плюсов, и как легко эти минусы обходятся практически, а не теоретически, как вы написали: «Видел это вживую на базе в несколько гигабайт». Если вы такой умный, то лучше предложите способ обойти ограничение в 100 миллионов записей виртуального режима SysListView32 (в MFC-обертке CListCtrl), как раз для целей использования интерфейса на технологии клиент-сервер.

izekia EmeryВ 8-ке он (сервер приложения) используется исключительно как посредник, а «зачем нам кузнец, кузнец нам не нужен».
без комментариев просто, зачем рассуждать о том чего не знаешь или о чем прочитано где-то и когда-то в инете? Может есть смысл поизучать вопрос более подробно?
А может есть смысл ответить по существу? Скажем, скрытый от непосвященных, смысл сервера приложения 1С8.х в том что, ну хотя бы, «это коммерческая тайна». Дадите интересную зацепку, «поизучаю подробнее», а так, не вижу особого смысла.

izekiaеще раз процитирую, причем здесь используемая технология, пусть даже в рамках 1С в77 и комфорт пользователя?
Еще раз говорю, что предпочитаю искать решения в С++, а не 1С. По 1С у меня нет вопросов. А по существу, чтобы организовать полноценный интерфейс (я имею в виду, прежде всего полный доступ к данным на уровне одновременного использования множества гридов или лист-контралов и их форм диалогов интерфейса, но без явных запросов) обычно используется технология типа «файл-сервер» (если знаете для «клиент-сервера», то подскажите). А для клиент-сервера типичен интерфейс в виде «тонкого» клиента, т.е. одной или несколько относительно простых форм, используемых, как правило, модально, позволяющих организовывать доступ к данным по явному запросу. Так вот, «тонкий» клиент значительно менее удобен для работы, чем «толстый». Что же тут непонятного? Другое дело, построить толстого клиента на основе технологии доступа к данным «клиент-сервер». Чтобы была свободная навигация по одновременному использованию множества таблиц БД, без всяких там ограничений по объему данных, не нужных фильтров и явных запросов. Это как раз то, что меня сейчас волнует и что я хочу реализовать в своем проекте на С++. Есть, что сказать по существу, пожалуйста, рад буду выслушать.

izekiaя лично просто не вижу смысла в этом высказывании.
но вот вывод: EmeryУже по тому, что задается такой вопрос, видно типичное отношение разработчика к своей программе, мол, «мне с ней не работать». мне очень нравится
Ладно, спишем все на издержки неявного общения…

izekiaпо поводу файлового варианта и использования сервера
тупой простой пример недавнего проекта, необходимо было связать часть кода написанного в Excel с данными из 1С причем единственный способ связи - хттп + большой объем данных, к примеру справочник сотрудники 24 000 элементов.
Ваш вариант реализации?
Ну, «техническое задание» надо бы формулировать поточнее. Что понятно одному, не факт, что понятно и другому. Чтобы врубиться в задачу, мне пришлось домысливать ее. Во-первых, я не понимаю смысла, зачем связывать код из одной системы с данными из другой? Может быть, имеется в виду построение отчета в экселе, на основе данных 1С? Причем данные из 1С выгружены в html-формате? Т.е. эксел должен достаточно быстро импортировать и может быть частично преобразовать данные из html-файла, достаточно большого объема, но сохраняющего табличную структуру. В данном случае, справочника сотрудников на 24 тысячи человек (это где ж работает столько народу?). Правильно ли я понял условие? Если так, то это задача для садо-мазо. Я к ним не отношусь. В этом случае, я бы построил отчет средствами VFP, работая непосредственно с базой данных dbf из 1С, опыт такой работы у меня имеется. Можно было бы воспользоваться системами построения внешних отчетов, типа FastReport. А если база данных расположена не в dbf, а базе данных SQL, то можно задействовать средства отчетов самой SQL (например, Reporting Services из MS SQL Server 2005). Можно также использовать VBA из самого эксела, с его помощью можно делать практически все, что хочешь, я же не знаю какой код там уже накропали. Ежели Excel работает медленно, то есть смысл посмотреть в сторону «Open office», говорят он работает на порядок быстрее, по этому поводу смотрите:
http://www.gotdotnet.ru/Forums/Office/513237.aspx
Короче, слишком много «если», чтобы ответить определенно, но думаю, я бы с этой проблемой справился. У нас говорят, что «это не проблема, а всего лишь задача».

Dima TНачну с конца:
EmeryПлюсы клиент-серверных решений я знаю, и минусы тоже. Вы же знаете минусы 1С77, но не знаете ее плюсов, и как легко эти минусы обходятся практически, а не теоретически, как вы написали: «Видел это вживую на базе в несколько гигабайт». Если вы такой умный, то лучше предложите способ обойти ограничение в 100 миллионов записей виртуального режима SysListView32 (в MFC-обертке CListCtrl), как раз для целей использования интерфейса на технологии клиент-сервер.
1С77 как язык разработки это мягко говоря недоразумение, очень скудный и ограниченный в функционале язык. Немного пописать пришлось и вывод для себя я сделал простой: "Пока есть возможность писать не в 1С я буду ей пользоваться", пока все идет нормально :)
Странно это слышать человеку, который профессионально занимается 1С77 (за это я получаю зарплату). Мой вывод противоположный, с «семеркой» можно иметь дело, возможностей его вполне достаточно для предприятия среднего (типа нашего) уровня, а возможности легко наращивать за счет внешних компонент. Даже без всяких внешних компонент можно легко подключить VFP как OLE (для vfp9.exe /regserver) или COM-сервер (для vfp9r.dll) и свободно выполнять любой код (prg/fxp/app/exe) Visual FoxPro в среде 1С. Работать с чистым VFP не вижу смысла и «Парус» тому пример, зато ядро VFP очень даже стоит применять в 1С, производительность его ненамного отстает от MS SQL Server. Единственное условие конфигурации должны быть 100% собственные. Я уже 4 года работаю с 1С и практически не чувствую в нем никаких ограничений. Причем имеется множество идей по оптимизации кода. Но все же хочется (ради собственного удовольствия) попробовать сделать достаточно универсальную 1С-независимую программу учета ресурсов и начислений на средних предприятиях. Судя по вашей информации, 1С у вас применяется для очень крупного предприятия. Для этих целей он совершенно не предназначен . Нужно было искать другое решение, оптимальное для корпоративного пользователя. Однако это совершенно некорректно говорить о недостатках 1С используемого на крупном предприятии. Вашим специалистам надо памятник поставить, за то, что вообще заставили работать систему. Тем не менее, никто не снимает ответственности с того, кто спроектировал такую концепцию ведения учета на вашей фирме. Возможно, объяснить можно тем, что хотели получить дешевое решение, но, «скупой платит дважды».

Раз уж здесь зашла речь о SysListView32, то, похоже, решение очевидно. Переводим число 100000000 в шестнадцатеричный вид, получаем 5F5E100. Ищем это значение в comctl32.dll. Находим его в трех местах. Везде код однотипный, типа: Т.е., если значение меньше 0 и больше 100 миллионов, то уходим нафиг. Понятно, что если заменить 5F5E100 на, скажем, FFFFFFFE, то получим предел на количество записей в базе данных, отображаемых в SysListView32, свыше 4-х миллиардов. Что вполне достаточно для наших целей :) .

Dima TВ чисто алгоритмических языках как С++ нет встроенного СУБД движка, поэтому там проше писать интерфейс, а задачи выборки данных возложить на SQL-сервер.
Вот, ради этого, я и пришел в С++. То, что нет здесь «нет встроенного СУБД движка», нормально. Он здесь и не нужен, не тот уровень языка. А выбор сервера базы данных, это уже дело вкуса, потребностей и возможностей. Для меня то главный вопрос как раз в интерфейсе, реализуемом на Си, точнее в способе его взаимодействия с базой данных. То, что я хочу реализовать можно достичь с помощью виртуального режима SysListView32, над этим я сейчас и работаю.

Dima TПро стоимость терминальных лицензий можно еще упомянуть.
Можно предложить программулину WinConnect:
http://www.thinsoftinc.com/download/WinConnect-ServerXP/setup.exe
Она тоже платная, но подешевле будет. Причем, если сильно захотеть, то можно написать ее аналог самостоятельно, она основана на относительно простой идее.

Dima TКак раз "толстый" клиент-сервер может притащить всю таблицу и пусть пользователь ее разглядывает если ему так уж это интересно. Что мешает дать возможность пользователю быстро открыть выборку по заранее введенному фильтру или показать все если он фильтр не знает как задать? Я так делаю, по крайней мере если всего не более 10000 записей. Это ограничивается только интерфейсом, т.е. его разработчиком.
Но я хочу другое. Чтобы можно было клиенту посмотреть 100 миллионов или даже 4 миллиарда записей базы данных в произвольной навигации по гриду или лист-контролу. Это не утопия и никаких ограничений по скорости, если использовать виртуальный режим SysListView32 и достаточно мощный сервер базы данных. Запросы клиента тут конечно есть, но они неявные, задаются его перемещениями клавиш (стрелки вверх/вниз, PageUp/PageDown, Home/End, перетаскивание мышью ползунка на полосе скроллинга). Хотя ничто не мешает задавать и явные запросы, например, перейти к записи номер такой-то. Тогда не будет ограничения типа ваших «10000 записей».

Dima TПо моему в этом огромный плюс 1С, в его убогости как языка, он настолько примитивен и ограничен что в коде гуру в состоянии разобраться бывший студент с полугодовым опытом работы и продолжить его сопровождать. Поэтому с точки зрения владельца бизнеса софт на 1С при всех недостатках лучше, т.к. найти профи в нормальном языке гораздо сложнее чем 1С-ника.
Думаю, что здесь есть элемент заблуждения. Я, например, когда начинал программировать на 1С, имел в наличии практически все стандартные конфигурации. И думал, что вот, щас, выберу лучшую, слегка подредактирую под свои нужды и будет мне счастье. Однако меня постигло сильное разочарование. Оказалось, что разбираться в чужом коде, особенно если его очень много, скажем мегабайты, неблагодарное занятие. До этого у меня уже был опыт программирования на Си, Паскале + Object Professional, FoxPro и даже, немного, на Клипере. Что касается чужих конфигураций на 1С, то первое, что меня удивило, это отсутствие у их авторов хорошего знания концепции учета, как таковой. Второе, что меня неприятно поразило, это небрежность программирования, основной принцип тяп-ляп, как-нибудь. Я не видел ни одной добросовестно сделанной конфигурации. Плюс еще продираться через дебри ужасно написанного кода. Это оказалось выше моих сил и я решил, что дешевле для моего душевного здоровья самому написать конфигурации с нуля, чем разгребать чужое *****. Даже если просто внести более менее заметные изменения приходилось шастать по всему коду, матерясь на его качество реализации. Видно было что «конфигурасты» не любили свою работу. Но главное открытие для меня было то, что братья Нуралиевы реализовали такую концепцию учета, причем на системном уровне, которая мне чужда органически. Скажем, на уровне бухгалтерии, это изобретение субконто фирмой 1С, как способа натурализации бухгалтерского учета. Но, «бухгалтерский учет», это не столько учет, сколько контроль за деятельностью предприятия и по большому счету чужд самому предприятию. Пришлось перевернуть эту конструкцию с головы на ноги. За основу взял «натуральный учет», как я его называю. Все вроде бы про него знают, но нигде не нашел явной и ясной формулировки. Многое надо было домысливать. Далее все стало прекрасно, провел детализацию «натурального учета» до такого уровня, чтобы стандартный учет (то бишь, контроль со стороны госорганов) вытекал из него как следствие, а не причина, как у братьев Нуралиевых. Далее, объектная модель 1С оказалось ниже плинтуса. Единственное, что там действительно необходимо, это объект «Справочник». Прочие объекты: «Документы», «Регистры», «Календари», «Журналы», «Операции», «Планы Счетов», «Субконто», «Проводки», «Виды и группы расчетов» мне абсолютно не нужны и я ими не пользуюсь. Однако их наличие мне не мешает. Так что мне не мало, много лишнего в 1С77 :) Практически во всех конфигурациях была масса глупостей, из-за относительно низкого уровня 1С-ников. Поэтому все их произведения пришлось выбросить на свалку. Я отнюдь не собираюсь утверждать, что пишу замечательный код, просто использую совершенно другую концепцию программирования, чем та, которые навязывает фирма 1С. Думаю, что в моем коде «бывший студент с полугодовым опытом работы», да и любой 1С-ник, с мышлением братьев Нуралиевых хрен разберется. Тем более что существенная часть кода (где-то пол-мегабайта) вынесена во внешнее приложение VFP. Чтобы понять мою концепцию, ему надо понять весь код, на что уйдет время сопоставимое с его разработкой (там у меня универсальный генератор отчетов чего стоит). Хотя, конечно, если код вылизан и прекрасно работает, то внести в него мелкое изменение не составит труда, что мы только что продемонстрировали на примере SysListView32. Но что касается полноценного сопровождения и поддержки моего или чужого кода сторонним специалистом, то это еще большой вопрос.