Comments 23
Суть подхода в LinqToSQL для доступа к данным, а экономия в Asp.Net-хостинге с включенным в него MSSQL. PostgreSQL, возможно, «судьба», но в других решениях.
Но также получается усложнение реализации + как я понял, переписывание интерфейса целиком + дополнительный специалист .Net, который тоже недёшево будет стоить (а может быть и несколько, если предприятие крупное).

Плюс самая главная то проблема — ширина каналов интернет у нас в России не шибко большая и для организаций стоит дорого, да и аптайм 100% никто не даст (хотя мало ли что… просто я таких не знаю). Да и если хостер окажется ненадёжным можно потерять данные (бэкапы конечно хорошо, но это большой простой в работе, если учитывать ширину канала связи).

В общем решение конечно необычное, но мне, кажется, что ещё рановато для подобных решений… инфраструктура не готова…
А можно уточнить какая такая «инфраструктура» не готова для нормальных современных web решений, но при этом готова к web интерфейсу самой 1С?
Вы хоть понимаете, о чем хотел сказать автор?
Конечно, он предложил вынести данные 1С изнутри сети на внешний хостинг.

Примерные проблемы которые будут я обрисовал, инфраструктура которая неготова в данном случае — каналы связи, потому как для маленькой компании такое решение не подойдёт, а в средних и выше будет много пользователей и канал захлебнётся. Также любое прерывание работы провайдера приведёт к абсолютной неработоспособности компании.

Веб интерфейс 1С в моём понимании — это позволить работать удалённым пользователям время от времени вне офиса. Но работа в офисе будет бесперебойной и вполне стабильной (по крайней мере, я общаюсь с неплохими 1С программистами, сертифицированными, из общения с ними я сделал такой вывод, хотя могу и уточнить, если я оказался неправ).

Тут же автор предлагает полностью уехать в интернет.

Я не говорю что это плохо, это будет рано или поздно, если всякие SOPA не помешают. Но сейчас, мне кажется, это просто утопичная идея.

P.S. тем более не путайте «web решения» и работу с 1С, веб — это больше чтения достаточно однородной информации, а 1С — больше записи данных и тяжёлых отчётов (причём используются они сотрудниками крайне неадекватно), потому на хостинг за 500руб/мес въехать точно не удастся.
Думаю вы не совсем поняли, что хотел сказать автор.

Постулат статьи в том, что они сделали возможность работы с базай 1С из внешней программы на .NET. И все. Если и упоминается где-то внешний хостинг, то вскользь и лишь как пример. .NET на вебе не заканчивается. С таким же успехом это может быть интеграция с другой учетной системой, билингом или еще чем-то. Т.е. автор не предлагал заменить 1С на веб. Они сделали продукт позволяющий упростить доступ к базам 1С и .NET. Как пример привели веб проект.
Который в некоторых случаях позволит с экономить на MSSQL сервере (который к слову совсем не дешев). Но ни слова о массовом переходе 1С в веб в статье нету.

Веб интерфейс в моём понимании — это просто веб интерфейс. Что он будет делать, вопрос второстепенный. Это может быть более легковесная замена некоторым десктопным функциям. А может это будет инет-магазин с такой вот связью через БД. Тут фантазия практически не ограничена применением.

Так что вы сделали слишком далеко идущие выводы, просто прочитав пример про веб.
Вы абсолютно правы, говоря, что применение не ограничено вебом. Веб был приведен как наиболее наглядный способ демонстрации. Примеры такие:
exportasia.ru — веб-реализация. Первые 2 скриншота из 1С для этого проекта.
Silverlight-реализация с данными из 1С: Предприятие
Простейший интернет-магазин, работающий как каталог. Исходные коды для него открыты и находятся здесь: www.richmedia.us
Пример публикации части данных для Упралвение Торговлей 10.3
Вы походу с 1С не работали… что Postgesql, что MSSQL, что ORACLE, все одно едино. Структура данных будет закрыта и это основная проблема.
Я это написал это к вопросу об экономии денежных средств.

1Сники, кстати, на 8ку не жалуются по поводу закрытости данных, мало того, очень хвалят, говорят намного удобнее работать чем с 7кой и проблем с производительностью БД таких нет.

C 1Ской я и с 7й и с 8й имел дело, мало того под 7кой мы больше 120 пользователей держали одновременно, работа стандартными средствами 1С 7ки этого не позволяет в принципе.
Классная, но к сожалению, плохоотформатированная статья. Может вы сможете отформатировать материал? Спасибо.
Извиняюсь, непривычное поведение хабра на тэг смутило. Отформатировал с добавлением
В сравнении с 1С: Предприятие .Net
Framework остается всего лишь набором несвязанных классов.

ну-ну…
случайно не путаете узкоспециализированный софт с фреймворком? или ожидалась функция Сделать_Отчет_По_Субконто?
Я не путаю узкоспециализированный софт с фреймворком, я их пытаюсь объединить в симбиоз.
симбиоз — это понятно, и более чем удобно. только
>набором несвязанных классов.
режет слух.
.NET является отличным фреймворком с продуманной архитектурой и с богатым функционалом.
Это бесспорно, что архитектура .Net продумана и богата на функционал. Но сам по себе он интереса не представляет, а ценен, когда все его классы объединяются в рамках специально написанного на его основе узкоспециализированного приложения. А до этого момента классы его несвязаны (оговрюсь, связаны в рамках пространств имен). Например, нет никакой связи между WPF- и LinqToSql-классами до тех пор, пока связь эту не выполнит приложение.
>Например, нет никакой связи между WPF- и LinqToSql-классами до тех пор, пока связь эту не выполнит приложение.

и это хорошо! LinqToSql прекрасно работает в своей сфере. WPF в своей.
при существовании такой зависимости — это была бы просто поделка, которую писали начинающие программисты. да еще и плохим тоном.
для сопряжения с сайтом онлайн — нужно использовать встроенные веб-сервисы 1с или comconnector, на крайняк.

в первом случае — у нас есть API, которое абстрагировано он веб стороны, во втором — работа с данными «напрямую», можно выбирать, что лучше в каждом конкретном случае.

преимущество перед прямым обращением к данным в том, что во первых — работают запрограммитрованные в 1с алгоритмы (например обработка проведения документа с контролем остатков и прочим), а также работают встроенные в платформу механизмы (расчет итогов регистров, УРБД и прочие).
Между словом «нужно» и выражением «можно еще» есть большая разница )))). Думаю, вашу фразу лучше читать так:
> для сопряжения с сайтом онлайн — можно еще использовать встроенные веб-сервисы 1с или comconnector, на крайняк.

Сколько существует 1С: Предприятие, столько же времени актуальна тема прямого доступа к данным 1С. Данный способ – это еще один способ в копилку способов сопряжений с 1С, которые вы перечислили. Его преимущество в том, что ему не нужны посредники в лице 1С, а, следовательно, работать он будет быстрее.
Описывая COM и веб-сервисы, нужно отметить их недостатки. Оба способа требуют дополнительных лицензий. COM-технология позволяет в каждый момент времени выполнять только один запрос. Обработка одновременных запросов для COM возможна, но требует затрат на организацию пула соединений и отладку многопоточного приложения. Ну и в C#-коде обращение к COM через InvokeMember выглядит не очень наглядно (может тип dynamic в .Net 4 решит эту проблему).
Веб-сервисы же сложны по своей настройке. Далеко не факт, что веб-сервисы позволят одновременное обращение к себе нескольких пользователей – не помню, чтобы проводились такие исследования. Есть комментарии в форумах, что часть проблем с веб-сервисами компанией 1С до сих пор не удалось решить, и они остались зарегистрированными багами. Это значит, что промучавшись, настроив веб-сервисы, запрограммировав их можно столкнуться с вообще нерешаемыми проблемами.
как COM, так и веб сервисы — требуют дополнительно одной лицензии (если таковой доступ осуществляется именно в рамках одного сеанса, т.е. для COM — одного узла веб-сервера, для веб-сервисов — одного сервера с веб сервером, публикующим веб-сервисы 1с). цена — до 4500 рублей.

стоимость же реализации бизнес-логики еще и на веб-стороне — бесценна. ну и одновременная доработка бизнес логики и в 1с и на сайте — мало удовольствия.

лично я — против обращения через COM, так как он не дает нормального контроля за тем, что же действительно делается в системе, веб сервисы — ограничивают возможности внешней системы предоставляемым нами API. прямой же доступ к данным — это вообще ходьба по минному полю — малейшая ошибка, и консистентности информационной системы можно сказать «до свидания».

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

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

резюме — я, как специалист по 1с, против прямого доступа к данным. основная причина — неконтролируемость этого процесса. ну и стоимость разработки и изменения.
ИМХО для Статья для Хабра совершенно неочем, нет технических деталей в принципе изложение в духе вот теория а реализация ну там ссылки есть код гляньте если не лениво. Похоже на «Я пиарюсь». По сути статьи: задумка очень хороша, и вариантов куда применить просто тьма. Но не все так в шоколаде как говорят авторы статьи, чтобы сэкономить на mssql достаточно внедрить Postge, сэкономить не выйдет вообще ни на чем, но как костыль может очень даже пригодится а с приходом управляемых форм в 8.2 область применения решения сужается очень сильно, клиент на УФ при продуманном подходе, вполне может работать с комфортом с gprs брелка с удаленной базой не ощущая каких либо затруднений.
Надо начать с того, что тема прямого доступа через LinqToSql к информационной базе 1С достаточно новая. Нужно быть последовательными. Перед появлением каких-то технических деталей не мешало бы дать теоретическое обоснование. Эта статья и есть теория.
С приходом управляемых форм 8.2 ничего не изменится в положительную сторону. На каждое подключение через веб нужно покупать лицензию. Представленный в статье способ не требует дополнительных лицензий. Не знаю, как сейчас и будет в будущем, но в 1С 8.2.13 клиентский html- и js- код просто ужасный: сильно избыточный и с ошибками. И не думаю, что веб-доступ через управляемые формы 8.2 применим для публичных сайтов, так как программист не волен управлять html- cs- кодом при генерации форм, а также не понятно как при существующем подходе в 1С 8.2 сделать автоматическую регистрацию пользователей или использовать, например, OpenID-подход при авторизации.
основной недостаток прямого доступа (в т.ч. LinqToSql) в том, что не выполняется никакого кода из 1с, соответственно, всё поведение системы нужно реализовывать еще раз.
>> Эта статья и есть теория
Теорию легко показать показать на практике если есть реализация, здесь есть просто рассуждения, простите если очень резко

>>На каждое подключение через веб нужно покупать лицензию. Представленный в статье способ не требует дополнительных лицензий.
Есть такое дело, никаких лицензий не хватит чтобы выложить в паблик вебдоступ к базе. Но это наверно глупо, есть сайты а есть десктоп приложение с фиксированным количеством пользователей, это все таки разные вещи, хорошие сайты с правильным кодом не задача 1С. Оставьте «OpenID-подход при авторизации» правильный код и все остальное вебмастерам а для обмена сайтом используйте XML, CommerceML или то что вам будет удобно
Only those users with full accounts are able to leave comments. Log in, please.