COM.v83 и windows-окружение. Для нас это не проблема, т.к. основное приложение у нас на .net и все равно нужны виндовые машины. Про comctrl.dll честно говоря не понял проблему, если речь про то, что на одной машине через него можно ходить только в одну версию платформы, то это как раз то, что нам нужно. Уточню, все эти нюансы относятся только к процедуре выкачивания метаданных из 1С, для выпонения запросов 1С не нужен.
Про другие Linq-провайдеры. Я смотрел на те из них, на которые есть ссылки со странички на github-е. Мне хотелось легкий и невербозный дизайн, бесплатность и open source. В них я этого не нашел. Возможно я пропустил какие-то другие решения.
У нас 5 физических баз PostgreSQL, на каждой из которых крутится около двухсот баз 1С, данные разводятся действительно стандартным разделителем «ОбластьДанныхОсновныеДанные». Не очень понял, какой от сюда вывод, Fresh умеет запускать запросы на всех клиентских базах?
Про задачи для бухгалтера — интересно, но нам в первую очередь нужно средство мониторинга, чтобы каждый день на скраме видеть, у каких бухгалтеров где проблемы. С задачами нам пришлось бы незакрытые задачи импортировать из каждой 1С-ной базы в нашу общую базу. Кроме того, если появляется новый вид проверки нам нужно будет как-то быстро добавить его во все наши тысячу баз. Это возможно сделать эффективно?
Metadata.js — смотрели, но у нас есть отдельное приложение на .net, которое помимо интеграции с 1С еще много полезной бизнес-логики крутит, так что в 1С ходить удобнее прямо из него.
MSSQL — там у нас лежит разная статистика из всевозможных источников, не только 1С, просто исторически так сложилось.
Про 10 часов в исходной задаче. Это суммарное время прогона всех запросов, реализующих наши проверки, на каждой из тысячи баз. По большей части там всевозможные хитрые проверки на дубликаты разных сущностей — контрагентов, договоров, документов.
Рекомендации 1С это одно, а реальная жизнь — немного другое. Вполне допускаю, что мы не знали про какие-то уже готовые решения, когда начинали делать эту штуку. Я вот, например, вообще c 1С первый раз связался пол года назад :) Поэтому спасибо вам за полезные ссылки и наводки. Тем не менее, проблемы нужно как-то решать, и у нашего подхода есть свои плюсы. Мы можем, например, очень быстро проверять гипотезы о бизнесе клиента, находить паттерны в данных и как-то реагировать на них.
Не знаю, может и проще. Все равно пришлось бы патчить запрос, хотя бы чтобы он по нужным нам областям работал, а не только по одной. Ну и от 1С зависимость: запрос меняется — нужно 1С дергать, а подключение к нему через COM — процесс очень не быстрый.
Да, вы правы, мы сейчас это не учитываем. Мы даже не учитываем, используется ли «ОбластьДанныхОсновныеДанные» конкретным объектом, и добавляем условие на равенство областей вообще ко всем джойнам в исходном запросе. Учитывать это не сложно, просто потребность не возникала.
Да, в конфигурации «1С: Бухгалтерия» есть специальный общий реквизит «ОбластьДанныхОсновныеДанные», который выступает таким универсальным разделителем. Это просто целочисленный идентификатор, 1С автоматически подставляет его для всех использующих объектов.
Не знал про эту библиотеку. Посмотрел бегло, судя по примерам, вроде это какая-то надстройка над regexp-ами? Там можно для не регулярных языков обычные грамматики писать?
еще немного поиcследовал вопрос:
1. в предыдущем эксперименте у меня стояла галочка Prefer32Bit, т.е. процесс из под wow64 был запущен. Если ее убрать, то время в ядре становится меньше гораздо, но все равно с работой программы продолжает расти
2. по стекам ProcessExplorer-а видно, что throw замыкается на RaiseException — стандартную
API функцию для генерации SEH-вских эксепшнов.
3. обработка SEH-вских фреймов (как и описано в вышеприведенных статьях) происходит в два
этапа — вначале RtlDispatchException ищет обработчик выше по стеку, затем этот обработчик вызывает RtlUnwind для снятия со стека всего лишнего (EXCEPTION_REGISTRATION-ов/активаций функций).
4. судя по частично доступным в сети сорцам винды 2000, единственное место, которое обращается
в ядро в этой схеме — это переход из RtlUnwind на найденный фрейм через системный сервис ZwContinue.
написал простой тест — в бесконечном цикле создаем исключение/пробрасываем/ловим — в ProcessExplorer-е
Kernel Time стабильно растет. Если в тесте оставить только создание класса исключения — Kernel Time не изменяется (win7, x64).
Этот контейнер отличается от Autofac, Structuremap и т.п. тем, что никогда не являлся самоцелью. В нем реализованы только те фишки, которые смогли существенно облегчить нам жизнь при решении конкретных задач. Поэтому, в частности, там нет понятия lifestyle-а — хоть и красивого теоретически, но приводящего к определенным сложностям в использовании и стыковке с другими фичами контейнера.
Уверен, что кое-что из описанного можно реализовать поверх Autofac — весть вопрос в том, какими усилиями и насколько простой код/конфигурация в итоге получится.
Согласен, что создание экземпляра — относительно дешевая операция, даже с учетом gc/memory traffic. Основной профит синглтонов — в их простоте для прикладного кода. Чтобы использовать внутри сервиса другой сервис нужно просто принять его в конструкторе. Точка использования ничего не знает о lifestyle-ах/dispose-ах — довольно второстепенных, по сути, вещах. Чтоб получить сервис, обладающий определенными характеристиками, нужно просто повесить на параметр конструктора атрибут с выразительным именем, а все эти характеристики формализовать в конфигураторах.
Суть в том, что DI-контейнер — штука, неизмеримо более простая, чем БД или операционная система. В идеале конечно-же мне хотелось бы целиком контролировать БД и ОС чтобы иметь возможность быстро править там баги и добавлять нужные мне фичи. И в другом масштабе (google, microsoft) это так и происходит.
Про фичи — я далеко не уверен, что популярные контейнеры поддерживают все из описанного и с нужным нам минимумом вербозности. Основная фишка этого контейнера в том, что он не предполагает сложного конфигурирования чтобы учесть все возможные сценарии своего использования. Он реализует только те convention-ы, которые показали себя полезными в нашей практике, и не более.
Как раз на Autofac я смотрел более пристально, чем на остальные, и аналогов не нашел. Здесь описано, как можно выбрать конкретную реализацию интерфейса в точке использования интерфейса — на уровне параметра конструктора типа ISender я могу атрибутом указать, что использоваться на самом деле должен EmailSender. Либо тоже самое можно сделать в соответствующей ему конфигурации. Контракты же в некотором смысле более общий механизм. Атрибутом я могу пометить не сам интерфейс, а целое дерево сервисов, которое где-то в своих листьях имеет замыкания на этот интерфейс. Деревья, помеченные разными атрибутами, будут автоматически созданы контейнером в нескольких экземплярах, т.к. имеют различные конфигурации для своих листьев. Основной пример — сложная бизнес-логика, реализуемая деревом сервисом и замыкающася на некоторый источник данных. В одном месте мне может быть нужно создать все это сложное дерево поверх файлового источника, а в другом — поверх базы данных. Причем у меня в системе будет всего два таких сервиса — контракты позволяют дать каждому из них имя и использовать по мере надобности в различных частях системы.
Большой проект, желание контролировать инфраструктуру и легко менять ее под потребности. К тому же, как писал уже выше, в проекте до моего прихода использовался этот контейнер, переходить на какой-то другой долго казалось занятием необоснованным и трудозатратным. Поэтому большинство описанных фич накручивалось поверх его публичного API. В какой-то момент мы просто поняли, что большая часть используемой нами логики контейнера уже реализована в виде таких костылей поверх API. В этот момент мы просто убрали старый контейнер, реализовав то немногое, что оставалось.
Но вообще на Unity такое можно сделать через расширения.
Я специально глубоко не исследовал популярные контейнеры — в наших условиях удобнее велосипед заточить было.
Но, насколько могу судить, чего-то похожего на контракты нет ни в одном из них.
COM.v83 и windows-окружение. Для нас это не проблема, т.к. основное приложение у нас на .net и все равно нужны виндовые машины. Про comctrl.dll честно говоря не понял проблему, если речь про то, что на одной машине через него можно ходить только в одну версию платформы, то это как раз то, что нам нужно. Уточню, все эти нюансы относятся только к процедуре выкачивания метаданных из 1С, для выпонения запросов 1С не нужен.
Про другие Linq-провайдеры. Я смотрел на те из них, на которые есть ссылки со странички на github-е. Мне хотелось легкий и невербозный дизайн, бесплатность и open source. В них я этого не нашел. Возможно я пропустил какие-то другие решения.
У нас 5 физических баз PostgreSQL, на каждой из которых крутится около двухсот баз 1С, данные разводятся действительно стандартным разделителем «ОбластьДанныхОсновныеДанные». Не очень понял, какой от сюда вывод, Fresh умеет запускать запросы на всех клиентских базах?
Про задачи для бухгалтера — интересно, но нам в первую очередь нужно средство мониторинга, чтобы каждый день на скраме видеть, у каких бухгалтеров где проблемы. С задачами нам пришлось бы незакрытые задачи импортировать из каждой 1С-ной базы в нашу общую базу. Кроме того, если появляется новый вид проверки нам нужно будет как-то быстро добавить его во все наши тысячу баз. Это возможно сделать эффективно?
Metadata.js — смотрели, но у нас есть отдельное приложение на .net, которое помимо интеграции с 1С еще много полезной бизнес-логики крутит, так что в 1С ходить удобнее прямо из него.
MSSQL — там у нас лежит разная статистика из всевозможных источников, не только 1С, просто исторически так сложилось.
Про 10 часов в исходной задаче. Это суммарное время прогона всех запросов, реализующих наши проверки, на каждой из тысячи баз. По большей части там всевозможные хитрые проверки на дубликаты разных сущностей — контрагентов, договоров, документов.
Рекомендации 1С это одно, а реальная жизнь — немного другое. Вполне допускаю, что мы не знали про какие-то уже готовые решения, когда начинали делать эту штуку. Я вот, например, вообще c 1С первый раз связался пол года назад :) Поэтому спасибо вам за полезные ссылки и наводки. Тем не менее, проблемы нужно как-то решать, и у нашего подхода есть свои плюсы. Мы можем, например, очень быстро проверять гипотезы о бизнесе клиента, находить паттерны в данных и как-то реагировать на них.
1. в предыдущем эксперименте у меня стояла галочка Prefer32Bit, т.е. процесс из под wow64 был запущен. Если ее убрать, то время в ядре становится меньше гораздо, но все равно с работой программы продолжает расти
2. по стекам ProcessExplorer-а видно, что throw замыкается на RaiseException — стандартную
API функцию для генерации SEH-вских эксепшнов.
3. обработка SEH-вских фреймов (как и описано в вышеприведенных статьях) происходит в два
этапа — вначале RtlDispatchException ищет обработчик выше по стеку, затем этот обработчик вызывает RtlUnwind для снятия со стека всего лишнего (EXCEPTION_REGISTRATION-ов/активаций функций).
4. судя по частично доступным в сети сорцам винды 2000, единственное место, которое обращается
в ядро в этой схеме — это переход из RtlUnwind на найденный фрейм через системный сервис ZwContinue.
написал простой тест — в бесконечном цикле создаем исключение/пробрасываем/ловим — в ProcessExplorer-е
Kernel Time стабильно растет. Если в тесте оставить только создание класса исключения — Kernel Time не изменяется (win7, x64).
Уверен, что кое-что из описанного можно реализовать поверх Autofac — весть вопрос в том, какими усилиями и насколько простой код/конфигурация в итоге получится.
Суть в том, что DI-контейнер — штука, неизмеримо более простая, чем БД или операционная система. В идеале конечно-же мне хотелось бы целиком контролировать БД и ОС чтобы иметь возможность быстро править там баги и добавлять нужные мне фичи. И в другом масштабе (google, microsoft) это так и происходит.
Про фичи — я далеко не уверен, что популярные контейнеры поддерживают все из описанного и с нужным нам минимумом вербозности. Основная фишка этого контейнера в том, что он не предполагает сложного конфигурирования чтобы учесть все возможные сценарии своего использования. Он реализует только те convention-ы, которые показали себя полезными в нашей практике, и не более.
Большой проект, желание контролировать инфраструктуру и легко менять ее под потребности. К тому же, как писал уже выше, в проекте до моего прихода использовался этот контейнер, переходить на какой-то другой долго казалось занятием необоснованным и трудозатратным. Поэтому большинство описанных фич накручивалось поверх его публичного API. В какой-то момент мы просто поняли, что большая часть используемой нами логики контейнера уже реализована в виде таких костылей поверх API. В этот момент мы просто убрали старый контейнер, реализовав то немногое, что оставалось.
Вы не могли бы пример привести?
Но, насколько могу судить, чего-то похожего на контракты нет ни в одном из них.