Теперь давайте разберем все ваши высказывания без фанатизма и без маркетинговых картинок. Тем более, что я бы постеснялся показывать комментарии перед определениями функций – весь мир давно уже перешел на XmlDoc. Хотелось бы и у 1С видеть что-то на ее манер в виде ///<описание></описание> <параметр></параметр>
Разрабатывать свои интерфейсы — это очень интересно, конечно, но даже если мы возьмем тот же .NET, все базовые интерфейсы уже реализованы, достаточно их выучить и научиться имплементировать правильно, так же и в 1С, уже есть все базывые интерфейсы, необходимости разработки чего-то своего нет. Множественность наследования — по сути, так же не нужна. (Приведите пример, когда в 1С она нужна?) События есть, как события объектов, так и события форм, события статических метаданных, так же как и гобальные подписки на события. Проверка типов есть ТипЗнч(Источник) говорит какой именно тим имеет объект Источник, сравнить его можно с типом полученным по конструктору Тип(«ПеречислениеСсылка.ВидыШтрихкодов») или Тип(«ДокументОбъект.РасходнаяНакладная») используется всегда в глобальных подписках на события в не типовых доработках, не снимающих с поддержки типовую конфигурацию.
Все базовые классы и интерфейсы в .Net конечно разработаны, но, тем не менее, .Net предполагает определять классы. А если бы наследования не было в .Net, использовать в статье класс Walker было бы невозможно, и решение задачи заняло бы раза в 3 больше времени (организация рекурсии, приведение типов). С чего вы взяли, что множественность наследования не нужна? Странно мыслите. В близких аналогах 1С: SAP и Axapta нужна, а в 1С – оказывается не нужна. Если ее нет в 1С, то это не значит, что она не нужна. Это значит, что 1С в меру своей ограниченности не может предоставить такую возможность. Соответственно и ТипЗнч, Тип – совершенно бесполезны, потому что они работают только с предопределенными классами.
Как оказалось, у подхода компилирования C# в код 1С могут быть еще достоинства. Разработка 1С из конфигуратора в теории может быть перемещена в Visual Studio со всеми преимуществами: intellisense, быстрый рефакторинг, контроль типов, встроенный контроль ошибок при компилировнии. Плюс контроль версий сторонними средствами (проект C# в виде файлов в папке). Возможно, юнит-тестирование. Еще код на C# более выразительный. Сложный проект можно разделить на модули-сборки проектов C#.
Вероятность того, что будет польза минимальная, потому что для успешного результата требуется: проработать трансляцию конструкций C# на 1C (встроенные типы, события, классы, generic-типы, лямбда выражения), сделать классы/методы-заглушки для всех объектов 1С (их очень много), собрать сообщество, поддерживать в актуальном состоянии с вновь выходящими фичами 1С.
Я интересовался вашим opensource-проектом, вы можете тоже проработать такой подход для других языков. Но в случае с VisualStudio/C# и сборками, в которые можно помещать все, что угодно, организовать трансляцию проще и удобнее.
Имелся ввиду объект compilation — с прописной буквой «C» — изменил в статье. Теперь выглядит так:
var compilation = CSharpCompilation.Create("1ccode").WithOptions(new CSharpCompilationOptions(OutputKind.DynamicallyLinkedLibrary)).AddReferences(new MetadataFileReference(typeof(object).Assembly.Location)).AddSyntaxTrees(tree);
var Model = compilation.GetSemanticModel(tree);
Мне был интересен ООП-подход в контексте модульности 1С. Можно ли разделить большое монолитное приложение 1С на малосвязанные модули. Что мне для этого не хватает из C#/Java: классы, наследование классов от какого-нибудь класса Module (может, интерфейсы IModule), атрибуты вида [Module], получение метаданных класса через GetType(), события, проверка типов «o is Module».
Как оказалось, у подхода компилирования C# в код 1С могут быть еще достоинства. Разработка 1С из конфигуратора в теории может быть перемещена в Visual Studio со всеми преимуществами: intellisense, быстрый рефакторинг, контроль типов, встроенный контроль ошибок при компилировнии. Плюс контроль версий сторонними средствами (проект C# в виде файлов в папке). Возможно, юнит-тестирование. Еще код на C# более выразительный. Сложный проект можно разделить на модули-сборки проектов C#.
Решения на одной платформе — без сомнения маркетинг, но он оправдан удобством.
В случае, когда разделен учет, не требуется интерактивности — достаточно раз в месяц выгружать данные, потому что бухгалтерские отчеты делаются раз в месяц. Этими задачами обычно занимаются разные люди. И, чаще всего, выгрузка делается в одном направлении. И даже в этом случае возникают постоянные разборки — кто переименовал такую-то номенклатуру или такого-то контрагента или кто изменил остатки задним числом.
В случае же добавления CRM (а CRM, скорее всего, будет добавляться к уже налаженной торговле) на бедного менеджера, который и так загружен заказами ложиться еще и обязанность вести взаимоотношения с клиентами. Понятно, что хочется ему сделать работу комфортной, чтобы он не переключался по разным окнам и по возможности при проведении заказа система продолжила бы бизнес-процесс автоматически, не требуя от него дополнительного действия в другом окне другой программы.
В том-то и дело, я не представляю, как выполнить бесшовную интеграцию 1С-системы и не 1С-системы CRM. Здесь проблемы возникают, когда интегрируются две 1С-системы: торговля и бухгалтерия, а в случае с не-1С системой проблем будет еще больше.
Конфликты могут возникнуть, если контрагент назывался, например, «Иванов С.И.», после обмена в двух системах он появился, но в какой-то момент в одной системе решили его переименовать в «Иванов Сергей Иванович», а во второй системе он остался по-прежнему. Соответственно в 2х системах — это 2 разных человека.
XML-хороший формат. Но обмен через него не дает интерактивной реакции одной системы на изменения в другой. Обычно обмены настроены на выполнение через какое-то время в автоматическом режиме. Ввел в 1С заказ и ждешь час/полчаса, пока он не придет в CRM. Опять же сформировать заказ с хитрыми автоскидками на стороне CRM, скорее всего, не получится. Потому что алгоритмы скидок жестко прописаны в 1С.
Мне кажется, что лучшая CRM в случае, если торговля ведется средствами 1С — это интегрированная в конфигурацию CRM, не обязательно от компании 1С. Тогда все изменения видны интерактивно, нет дублирования данных, работа ведется практически из одного окна.
И еще ваша фраза «любая современная CRM способно интегрироваться с 1С «на раз»»
напомнила фразу, когда мы выбирали систему контроля доступа — «наша система СКД легко интегрируется с 1С». Когда стали выяснять, оказалось у СКД есть базовая интеграция с конфигурацией ЗУП. Понятно, что 1С этой конфигурацией не ограничивается, и понятно, что конфигурация может быть сильно изменена. Поэтому давайте маркетинговые заявления отделять от практики.
Не сочтите мои комментарии придирками. Сейчас выбираем CRM для своего предприятия.
А вот CRM (не Битрикс, а именно CRM) у 1С имеет великое множество недостатков
Я не имею ввиду CRM от самой компании 1С. Слышал, что более распространены CRM на базе 1С от других производителей.
Что касается импорта/экспорта, не смешите пользователей, любая современная CRM способно интегрироваться с 1С «на раз», ни разу не слышал, что это проблема
Интересно было бы узнать о таких «несмешных» способах интеграции подробнее. Пользователь должен держать 2 окна открытыми: 1С с заказами и окно CRM? Бизнес процесс CRM дошел до задачи ввести заказ покупателя, пользователь открыл 1С, ввел заказ, переключился в CRM и ввел номер заказа в CRM, чтобы продолжить БП? CRM и 1С хранят один и тот-же набор контрагентов, номенклатуры, заказов и при редактировании в одном месте возникают конфликты в другом? Менеджер обзванивает клиентов из CRM и вынужден переключаться в 1С и смотреть их задолженность? Или это как-то по-другому реализовано в нормальных интеграциях?
Вопреки своему принципу не рассматривать продукты 1С
Интересный принцип, судя по распространенности 1С. Этот принцип чем-то обоснован?
Ведь у многих стоит 1С: Управление Торговлей, и логично/разумно иметь CRM-систему полностью интегрированную в конфигурацию 1С?
Это избавит от постоянного импорта/экспорта данных между системами, а также из одной подсистемы позволит открывать формы другой подсистемы в 1 клик. Или есть какие-то недостатки?
Русский язык программирования для русскоязычных конфигураций — это плюс, также как английский в англоязычной 1C Accounting Suite. Родной язык позволяет не задумываться, как перевести на иностранный высказывания бухгалтеров. Потому что не все владеют английским, а местный перевод некоторых слов рассмешит иностранцев. Попробуйте, например, сразу перевести «Единица измерения», «Контрагент», «Расходный кассовый ордер». Русский язык программирования появился как следствие по-русски написанных понятий, чтобы постоянно не переключать раскладку.
Кстати, весьма удачно, что C# и Asp.Net позволяют называть классы и члены классов по-русски. Это убыстряет интеграцию с 1С, но заставляет постоянно переключать раскладку.
На отсутствии модульности правильно акцентировали внимание. В свое время занимался проблемой модульности 1С infostart.ru/public/192074/
Модульность можно реализовать в некотором приближении. Не понятно, правда, что делать с формами, которые монолитны по сути, в которых нет понятия пользовательских компонентов.
Не понятно еще чем занимается БСП, которая вошла в основу всех популярных конфигураций. Возможно, она должна была решать проблему модульности, но со временем стала неповоротливой и монолитной. Чтобы вычленить только подсистему работы с пользователями или только подсистему работы с файлами, нужно переработать кучу мест, убрать завязки на другие подсистемы. Подсистема разделения данных в ней тоже неочевидным способом работает.
Возможно, модульность — это только мечта. И ее реализация средствами 1С очень негативно скажется на скорости работы приложений. Недавно сравнивал скорость работы написанного на 1С JSON-сериализатора и XML-сериализатора, вшитого в платформу. Скорость кода 1С в 30 раз медленнее. Это значит, что модульность, реализованная на 1С, а не вшитая в платформу может дать существенное замедление, поэтому 1С отказалась от нее.
Отличная статья. Писал декомпилятор 1С-опкода примерно по такому же принципу. Все работает идеально, пока не применены специальные средства защиты.
Как обстоят дела в вашем случае, если .Net-сборка обфусцирована?
Исследовал в свое время возможности разделения данных в БСП-подобных конфигурациях. В БСП есть встроенные механизмы выгрузки и загрузки данных в область.
Выгрузка через ОбщаяФорма.ВыгрузкаДанных, загрузка через ОбщаяКоманда.ЗагрузитьДанныеВОбласть
Не нашел один момент. Может вы сталкивались. Существует ли возможность выполнения запроса по нескольким разделенным областям из сеанса с выключенным разделением?
Хорошая попытка интеграции. Подобная проблема стояла при интеграции 1С и .Net. Старый API 1С удалось подружить, а интеграция с новым вываливается в проблему LoaderLock.
Реализация для конкретно наших задач работала в 2 раза быстрее самого быстрого доступного на рынке альтернативного решения.
Вы рассматривали альтернативные форматы? Если да, то какие известные форматы дали большую производительность чем JSON? В итоге в каком виде сериализуются ваши данные?
Одна из немногих ситуаций, когда для решения перечисленных задач больше подойдет 1С, опубликованная через веб. Позволит гибко настраивать систему под специфику бизнеса и получить более красивые скриншоты.
Спасибо, что проинформировали. Может еще просветите, какие затруднения вызовет написание тестов для методов, описанных в статье? Хоть убейте меня, не могу понять — если есть метод, известно, чем он занимается, что на входе, а что на выходе — почему нельзя проверить правильно ли он сработал или нет.
Все базовые классы и интерфейсы в .Net конечно разработаны, но, тем не менее, .Net предполагает определять классы. А если бы наследования не было в .Net, использовать в статье класс Walker было бы невозможно, и решение задачи заняло бы раза в 3 больше времени (организация рекурсии, приведение типов). С чего вы взяли, что множественность наследования не нужна? Странно мыслите. В близких аналогах 1С: SAP и Axapta нужна, а в 1С – оказывается не нужна. Если ее нет в 1С, то это не значит, что она не нужна. Это значит, что 1С в меру своей ограниченности не может предоставить такую возможность. Соответственно и ТипЗнч, Тип – совершенно бесполезны, потому что они работают только с предопределенными классами.
Вероятность того, что будет польза минимальная, потому что для успешного результата требуется: проработать трансляцию конструкций C# на 1C (встроенные типы, события, классы, generic-типы, лямбда выражения), сделать классы/методы-заглушки для всех объектов 1С (их очень много), собрать сообщество, поддерживать в актуальном состоянии с вновь выходящими фичами 1С.
Я интересовался вашим opensource-проектом, вы можете тоже проработать такой подход для других языков. Но в случае с VisualStudio/C# и сборками, в которые можно помещать все, что угодно, организовать трансляцию проще и удобнее.
Как оказалось, у подхода компилирования C# в код 1С могут быть еще достоинства. Разработка 1С из конфигуратора в теории может быть перемещена в Visual Studio со всеми преимуществами: intellisense, быстрый рефакторинг, контроль типов, встроенный контроль ошибок при компилировнии. Плюс контроль версий сторонними средствами (проект C# в виде файлов в папке). Возможно, юнит-тестирование. Еще код на C# более выразительный. Сложный проект можно разделить на модули-сборки проектов C#.
В случае, когда разделен учет, не требуется интерактивности — достаточно раз в месяц выгружать данные, потому что бухгалтерские отчеты делаются раз в месяц. Этими задачами обычно занимаются разные люди. И, чаще всего, выгрузка делается в одном направлении. И даже в этом случае возникают постоянные разборки — кто переименовал такую-то номенклатуру или такого-то контрагента или кто изменил остатки задним числом.
В случае же добавления CRM (а CRM, скорее всего, будет добавляться к уже налаженной торговле) на бедного менеджера, который и так загружен заказами ложиться еще и обязанность вести взаимоотношения с клиентами. Понятно, что хочется ему сделать работу комфортной, чтобы он не переключался по разным окнам и по возможности при проведении заказа система продолжила бы бизнес-процесс автоматически, не требуя от него дополнительного действия в другом окне другой программы.
Конфликты могут возникнуть, если контрагент назывался, например, «Иванов С.И.», после обмена в двух системах он появился, но в какой-то момент в одной системе решили его переименовать в «Иванов Сергей Иванович», а во второй системе он остался по-прежнему. Соответственно в 2х системах — это 2 разных человека.
XML-хороший формат. Но обмен через него не дает интерактивной реакции одной системы на изменения в другой. Обычно обмены настроены на выполнение через какое-то время в автоматическом режиме. Ввел в 1С заказ и ждешь час/полчаса, пока он не придет в CRM. Опять же сформировать заказ с хитрыми автоскидками на стороне CRM, скорее всего, не получится. Потому что алгоритмы скидок жестко прописаны в 1С.
Мне кажется, что лучшая CRM в случае, если торговля ведется средствами 1С — это интегрированная в конфигурацию CRM, не обязательно от компании 1С. Тогда все изменения видны интерактивно, нет дублирования данных, работа ведется практически из одного окна.
напомнила фразу, когда мы выбирали систему контроля доступа — «наша система СКД легко интегрируется с 1С». Когда стали выяснять, оказалось у СКД есть базовая интеграция с конфигурацией ЗУП. Понятно, что 1С этой конфигурацией не ограничивается, и понятно, что конфигурация может быть сильно изменена. Поэтому давайте маркетинговые заявления отделять от практики.
Я не имею ввиду CRM от самой компании 1С. Слышал, что более распространены CRM на базе 1С от других производителей.
Интересно было бы узнать о таких «несмешных» способах интеграции подробнее. Пользователь должен держать 2 окна открытыми: 1С с заказами и окно CRM? Бизнес процесс CRM дошел до задачи ввести заказ покупателя, пользователь открыл 1С, ввел заказ, переключился в CRM и ввел номер заказа в CRM, чтобы продолжить БП? CRM и 1С хранят один и тот-же набор контрагентов, номенклатуры, заказов и при редактировании в одном месте возникают конфликты в другом? Менеджер обзванивает клиентов из CRM и вынужден переключаться в 1С и смотреть их задолженность? Или это как-то по-другому реализовано в нормальных интеграциях?
Интересный принцип, судя по распространенности 1С. Этот принцип чем-то обоснован?
Ведь у многих стоит 1С: Управление Торговлей, и логично/разумно иметь CRM-систему полностью интегрированную в конфигурацию 1С?
Это избавит от постоянного импорта/экспорта данных между системами, а также из одной подсистемы позволит открывать формы другой подсистемы в 1 клик. Или есть какие-то недостатки?
то не очень подходит для англоязычных конфигураций
Кстати, весьма удачно, что C# и Asp.Net позволяют называть классы и члены классов по-русски. Это убыстряет интеграцию с 1С, но заставляет постоянно переключать раскладку.
infostart.ru/public/192074/
Модульность можно реализовать в некотором приближении. Не понятно, правда, что делать с формами, которые монолитны по сути, в которых нет понятия пользовательских компонентов.
Не понятно еще чем занимается БСП, которая вошла в основу всех популярных конфигураций. Возможно, она должна была решать проблему модульности, но со временем стала неповоротливой и монолитной. Чтобы вычленить только подсистему работы с пользователями или только подсистему работы с файлами, нужно переработать кучу мест, убрать завязки на другие подсистемы. Подсистема разделения данных в ней тоже неочевидным способом работает.
Возможно, модульность — это только мечта. И ее реализация средствами 1С очень негативно скажется на скорости работы приложений. Недавно сравнивал скорость работы написанного на 1С JSON-сериализатора и XML-сериализатора, вшитого в платформу. Скорость кода 1С в 30 раз медленнее. Это значит, что модульность, реализованная на 1С, а не вшитая в платформу может дать существенное замедление, поэтому 1С отказалась от нее.
Как обстоят дела в вашем случае, если .Net-сборка обфусцирована?
Выгрузка через ОбщаяФорма.ВыгрузкаДанных, загрузка через ОбщаяКоманда.ЗагрузитьДанныеВОбласть
Не нашел один момент. Может вы сталкивались. Существует ли возможность выполнения запроса по нескольким разделенным областям из сеанса с выключенным разделением?
Вы рассматривали альтернативные форматы? Если да, то какие известные форматы дали большую производительность чем JSON? В итоге в каком виде сериализуются ваши данные?