Здравствуйте, IT, Вы писали:

IT>>>Ну хотя бы длительность и частоту вызовов.
ГВ>>Для каждого метода БЛ? Или для каждого метода, вызываемого клиентским приложением?
IT>Последнее.

Хорошо. Значит, нужно повесить счётчики на каждый открытый для внешнего клиента вызов. Особой проблемы нет. Почему? Потому что, если например, мы говорим о COM-вызовах, то у меня они редко непосредственно вплетены в структуру приложения, а находятся во внешнем, интерфейсном слое. Соответственно, реализация этого слоя всегда обвешивается трассировками/логами и прочей лабудой. Т.е., вот такая конструкция:

HRESULT SomeClass::getSomeValue(LONG *retVal)
{
  COM_CALL_TRACE(SomeClass, getSomeValue)
    //...
}

в порядке вещей. Итак, для решения твоей задачи мне потребуется только доработать COM_CALL_TRACE и перекомпилить проект. Скорее всего, я бы сделал контекстную замену на... ну, скажем, такую конструкцию:

HRESULT SomeClass::getSomeValue(LONG *retVal)
{
  COM_CALL_TRACE_TMDEF(TraceMode<Logged>, SomeClass, getSomeValue)
    //...
}

И здесь, кстати, мне на помощь и пришла бы декомпозиция — для выделения параметра TraceMode и уже его параметра (или атрибута?) — Logged.

Т.е., подход состоит в:

— декомпозиции исходной задачи на сущности (вызов функции, трассировочный вызов, параметры трассировочного вызова);

— комбинирования выделенных сущностей либо в теле трассируемых функций либо в отдельных функторах вроде TraceCall(...).

Возможно, что в каком-то случае и на какое-то определённое время использование AspectC++ тоже будет полезным, но при прочих равных я бы предпочёл явные модификации исходного кода. Почему? Очень просто. Представим возможное развитие твоей ситуации. Появляется ещё 10 методов, которые логгировать не нужно. Что нужно сделать? По идее — модифицировать описание композиционного фильтра, но важно не забыть об этом. А в пиковом случае композиционный фильтр будет содержать перечисление всех методов, на которые навешиваются дополнительные аспекты, т.е., задача будет по сложности практически равна простой вставке строк в функции... Вопрос в том, что это за строки.

Поэтому, точно так же я бы поступил, даже если бы вызовов COM_CALL_TRACE(...) изначально не было расставлено: в конце концов, даже 500 очень простых модификаций пусть и бестолковая по характеру, но в данном случае — одноразовая работа. Её несложно автоматизировать макросами VS а результаты очень пригодятся в будущем.

Так что, на мой взгляд, подход "с декомпозицией" будет не хуже аспектного, поскольку необходимые изменения функций сосредоточатся в самих функциях, а не расползутся неизвестно где (почему, кстати, у меня АОП и вызывает пока неоднозначное впечатление).

Предположим теперь, что компонентная технология не используется, т.е., у меня есть свой навороченный framework, который перенаправляет внешние вызовы объектам-реализациям. Ключевое слово: "framework". Он и займётся счётчиками.

Здравствуйте, mikа, Вы писали:

M>Твое решение: унаследовать все сущности от CBO, сделать с ними общение через ремотинг (между машинами), чтобы тормоза особо не ощущались. Это АОП.

Слушай, я уже устал от твоей демагогии. Я никаких решений не предлагал, я смиренно жду решения от ГВ.

M>Мое решение: внести функциональность в провайдеры, через которые идет взаимодейтствие с бизнес-сущностями. Это ООП.

Давай примерчик своего провайдера. Посмотрим что к чему.

IT>>Если рефлекшин использовать с умом и там где это уместно, то никаких проблем с ним не возникает.

M>Забавно, но пока ты предлагаешь обратное

Опять демагогия? Где именно что я предлагал.

M>Я это к тому, что использовать ремотинг в кокретной задаче в пределах одного домена — расточительство.

Ну и? Ты думаешь ты сделал открытие, кто-то был против?

IT>>Ну покажи мне в Роторе то место где создаётся и вызывается RealProxy средствами ООП.

M>Зачем же так далеко смотреть. Я тебе просто сказал, что RealProxy в Нете реализован с подходом ООП. Как тому подтверждение — это наследование его от класса System.Object. Мысли проще, зачем так все усложнять.

А ты в курсе каким способом вызывается RealProxy? Может продемонстрируешь как это сделать без готовой .NET реализации?

Здравствуйте, IT, Вы писали:

IT>Слушай, я уже устал от твоей демагогии. Я никаких решений не предлагал, я смиренно жду решения от ГВ.

Лови.

Автор: Геннадий Васильев
Дата: 25.01.04

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Т.е., подход состоит в:

Обычный старый дедовский способ, ничего нового

ГВ>Возможно, что в каком-то случае и на какое-то определённое время использование AspectC++ тоже будет полезным, но при прочих равных я бы предпочёл явные модификации исходного кода. Почему? Очень просто. Представим возможное развитие твоей ситуации. Появляется ещё 10 методов, которые логгировать не нужно. Что нужно сделать? По идее — модифицировать описание композиционного фильтра, но важно не забыть об этом. А в пиковом случае композиционный фильтр будет содержать перечисление всех методов, на которые навешиваются дополнительные аспекты, т.е., задача будет по сложности практически равна простой вставке строк в функции... Вопрос в том, что это за строки.

А если я забуду воткнуть твои строки в вызываемые методы? А если мне захочется добавить ещё немножко аспектов? А вдруг заказчик одумается и решит отключить всё это нафиг? Каждый раз контекстный поиск замена?

ГВ>Поэтому, точно так же я бы поступил, даже если бы вызовов COM_CALL_TRACE(...) изначально не было расставлено: в конце концов, даже 500 очень простых модификаций пусть и бестолковая по характеру, но в данном случае — одноразовая работа. Её несложно автоматизировать макросами VS а результаты очень пригодятся в будущем.

Да здравствует Copy/Paste — самая продвинутая технология индусов и китайцев

ГВ>Так что, на мой взгляд, подход "с декомпозицией" будет не хуже аспектного, поскольку необходимые изменения функций сосредоточатся в самих функциях, а не расползутся неизвестно где (почему, кстати, у меня АОП и вызывает пока неоднозначное впечатление).

Подход copy/pas... простите, "с декомпозицией" как я понимаю, это и есть твоя главная идея. Понял.

Здравствуйте, IT, Вы писали:

ГВ>>Т.е., подход состоит в:
IT>Обычный старый дедовский способ, ничего нового

Угу, ничто не ново под Луной.

IT>А если я забуду воткнуть твои строки в вызываемые методы? А если мне захочется добавить ещё немножко аспектов? А вдруг заказчик одумается и решит отключить всё это нафиг? Каждый раз контекстный поиск замена?

А ты подумай, какие именно строки надо воткнуть и что поставить за этими строками, чтобы потом к ним не возвращаться.

ГВ>>Поэтому, точно так же я бы поступил, даже если бы вызовов COM_CALL_TRACE(...) изначально не было расставлено: в конце концов, даже 500 очень простых модификаций пусть и бестолковая по характеру, но в данном случае — одноразовая работа. Её несложно автоматизировать макросами VS а результаты очень пригодятся в будущем.
IT>Да здравствует Copy/Paste — самая продвинутая технология индусов и китайцев

А где ты там copy/paste в его страшной ипостаси увидел? Я не фрагменты кода копирую, а всего-то дублирую сигнатуру вызова. Собственно, COM_CALL_TRACE_TMDEF(...) можно и не вводить. Хватит и разумно применённых частичных специализаций в реализации COM_CALL_TRACE(...).

ГВ>>Так что, на мой взгляд, подход "с декомпозицией" будет не хуже аспектного, поскольку необходимые изменения функций сосредоточатся в самих функциях, а не расползутся неизвестно где (почему, кстати, у меня АОП и вызывает пока неоднозначное впечатление).
IT>Подход copy/pas... простите, "с декомпозицией" как я понимаю, это и есть твоя главная идея. Понял.

Ну, как уж понял — так уж и понял.

Здравствуйте, beretta, Вы писали:

ГВ>>Очень забавно — я тебе о том, что прежде чем куда-то ехать, нужно разобраться с картами, а ты предлагаешь лететь по пачке беломора и преодолевать препятствия. Ну что ж, давай поупражняемся.
B>Стоит? Имхо это мат в 2 хода.
"А точка усмехнулась и стала запятой" (c).

B>У меня несколько иное представление к реализации нежели АОП, но раз разговор о признании самой проблематики. То я бы ответил словами классика о том, что нельзя объять необъятное. Проектирование вещь мощная и полезная, но имеет свой предел, обусловленный знанием (по специальности, предметной области) на текущий момент.
Именно поэтому всегда нужно думать хоть на полшага вперёд и анализировать максимум доступной информации.

Здравствуйте, Геннадий Васильев, Вы писали:

IT>>А если я забуду воткнуть твои строки в вызываемые методы? А если мне захочется добавить ещё немножко аспектов? А вдруг заказчик одумается и решит отключить всё это нафиг? Каждый раз контекстный поиск замена?

ГВ>А ты подумай, какие именно строки надо воткнуть и что поставить за этими строками, чтобы потом к ним не возвращаться.

Да хоть думай, хоть не думай, мантейнить это всё кому-то придётся.

ГВ>Ну, как уж понял — так уж и понял.

Как объяснил, так и понял

Здравствуйте, IT, Вы писали:

IT>>>А если я забуду воткнуть твои строки в вызываемые методы? А если мне захочется добавить ещё немножко аспектов? А вдруг заказчик одумается и решит отключить всё это нафиг? Каждый раз контекстный поиск замена?
ГВ>>А ты подумай, какие именно строки надо воткнуть и что поставить за этими строками, чтобы потом к ним не возвращаться.
IT>Да хоть думай, хоть не думай, мантейнить это всё кому-то придётся.
Ровно как и в случае использования АОП-компилятора.

Здравствуйте, Геннадий Васильев, Вы писали:

IT>>Да хоть думай, хоть не думай, мантейнить это всё кому-то придётся.
ГВ>Ровно как и в случае использования АОП-компилятора.

Не совсем. Классы бизнес логики трогать не надо будет. Этим вообще могут заниматься разные люди и песнях про большие проекты даже разные подразделения.

Здравствуйте, IT, Вы писали:

IT>>>Да хоть думай, хоть не думай, мантейнить это всё кому-то придётся.
ГВ>>Ровно как и в случае использования АОП-компилятора.

IT>Не совсем. Классы бизнес логики трогать не надо будет. Этим вообще могут заниматься разные люди и песнях про большие проекты даже разные подразделения.

Ну... не сказал бы, что я предлагаю такие уж сильные изменения в БЛ-классах. Зацепили framework — и поехали. Дальше всё равно по месту смотреть надо, у обоих стратегий есть свои плюсы и минусы.

Здравствуйте, Геннадий Васильев, Вы писали:

IT>>Не совсем. Классы бизнес логики трогать не надо будет. Этим вообще могут заниматься разные люди и песнях про большие проекты даже разные подразделения.

ГВ>Ну... не сказал бы, что я предлагаю такие уж сильные изменения в БЛ-классах.

Небольшие изменения тут, небольшие там и вот перед нами каша из логики и вспомогательного кода.

ГВ>Зацепили framework — и поехали.

Приципили из BL кода?

ГВ>Дальше всё равно по месту смотреть надо, у обоих стратегий есть свои плюсы и минусы.

О! Прогресс на лицо

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, naje, Вы писали:

N>>+ всё это можно приправить всякими рюшечками типа переопределеных операторов [],(),->, более удачных названий, генерации структур Action1 по обычным методам класса(правда перечисл. в каком-нибудь листе типов), то что делает ProxyHlpr можно разнести в разные классы, чтоб удобней специализировать было, специализировать его можно не по класу и действию, а по групе класов и действий, ну и куча других приёмчиков, которые к этому топику отношения не имеют

IT>Понятно. Реализуем паттерн Proxy. В общем, до простоты AOP тут как на четвереньках до Парижа. Особенно мне понравился вызов метода:

IT>

IT>obj.Do<MyClass::Action1>(Tuple(12,Aliased<xParam>(2)));
IT>

IT>Очень наглядно. Хотя, конечно, в качестве job security очень даже ничего

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

ты лучше ответь на такой вопрос, что если этот заказчик из твоего вопроса захочет не мониторинг добавить, а производительность неимоверную, и/или чтоб програмка вместе с операционкой помещалась на флэшку 8 МБ (такой запрос более реальный чем просьбя о мониторинге), а у тебя всё с испольлванием RealProxy уже написано
что делать?

Разрешите вмешаться, насчет задачки по счетчикам?

В моей практике я никогда не создавал бизнес объекты (БО) напрямую — они всегда создаются некоей фабрикой (или другим БО, выступающим в ее роли) Т.е. запросили сессию, у нее — некий БО, у того следующий и т.д.
Вся логика построена на открытых абстрактных (полностью, либо частично, или даже вовсе не абстрактных, но весьма полиморфных) классах.

Изначально, как я понял, встала задача — развесить хуки на вызовы методов (счетчики, мониторинг и т.д.),
так вот, для полиморфных методов это можно решить весьма даже многими способами

лопата begin {
учитывая, что по-сути нам требуется посадить именно хук, будим хачить:

1. COM — из typelib берем информацию об интерфейсе и в рантайме делаем ему заместитель, совместимый по vf_table, который в каждом методе вызывает наш хуковый счетчик, а потом вызывает (вызывает — громко сказано... делает jump на ) первоначальный метод замещенного метода интерфейса. При возврате ссылки на некий интерфейс — возвращаем прохаканный заместитель, если возвращаемый объект до этого не прохакан (это легко проконтроллировать)

2. С++ — ручками и только ручками в наследнике делаем вышеописанное для каждого метода, а лучше в самих методах. Комбинируя различные возможности С++, можно буквально одной строчкой в начале каждого метода добиться практически чего угодно — самый гибкий вариант, учитывая макроподстановки и шаблоны. (Вариант Г.В.)

3. .Net — очень много способов как сделать... выбираем на вкус... мне больше всего нравится идея в рантайм генерировать по typeinfo скриптинг, который делает нечто типа 1. и 2. но на "человеческом" .net ЯП, напр. С#
Вполне допустимый подход, ибо после компиляции и "переваривания" Jit быстродействие такого объекта в точности равно быстродействию обычного, расходуем время только на автогенерацию и компиляцию скрипта — но это все одноразово, 1 раз на класс (в отличии от CBO, где рефлекшн используется в каждом вызове, что действительно приемлимо разве что в Remouting, где это тонет в общих временных затратах).
} лопата end;

Ну а теперь вернемся в "человеческое" ООП.
Предложенная задача — неожиданная потребность начать мониторинг вообще всех вызовов — явно из разряда особенных (надуманных). Решение подобной задачи надо или проектировать вместе с фреймворком, или потом дорабатывать вообще все и ругать себя за скудоумие. Ибо ООП предполагает затрату некоей мыслительной энергии на начальных этапах проектирования.

Тема крайне интересная, и хотелось бы от IT услышать хоть один достойный пример, где АОП имело бы преимущество перед ООП. Хуки не предлагать , в реальных системах хуки делаются путем хаков (Win32). Интересно услышать задачу, относящуюся к целевым бизнес-объектам, а не к вспомогательным/системным вещам. (системного рода задачки на С++ весьма весело решаются, и никто не придерживается строгого ООП, если речь идет о чем-то весьма системном, типа представлении стека как списка параметров, в одной из своих библиотек на С++ я именно так и делал и даже больше, ибо возможность произвольной реинтерпретации произвольного участка памяти в С++ есть, хоть это и опускает нас на уровень древнего С... кстати, многое из Remouting в .Net именно на таком уровне и сделано, весьма это далеко от АОП и ООП)

И еще, самое главное:
Если не трудно, развития ради, интересно посмотреть на код и оценить трудоемкость подхода IT в решении его собственной задачки. ГВ предложил одну строчку кода на все интересующие методы, трудоемкость в этом случае ясна и понятна. IT, давай решение на АОЯП — справедливости ради, а то пока не ясно как все это сравнивать

Здравствуйте, vdimas, Вы писали:

V>(в отличии от CBO, где рефлекшн используется в каждом вызове,

В MBR (и CBO который ничем от MBR, кроме механики инициации не отличается) рефлекшен не используется. TransparentProxy это и есть то о чем ты говоришь, только реализованое прямо в JIT, т.е. не требующее компиляции вобще, а значит заведомо более быстрое чем то что ты предлагаешь. Тормоза ремоутинга не из-за тормозных проксей, а из за цепочки синков — и формирователи сообщений, и форматтеры и транспортные синки это очень небыстрая операция, поскольку, как правильно заметил IT, механика проксей предназначена не для перехвата вызовов, а для работы ремоутинга. Потому и получается что при вызове через контекст происходит море лишних действий, в том числе и с использованием рефлекшена (для работы форматтера и запуска сообщения).

V>Ну а теперь вернемся в "человеческое" ООП.
V>Предложенная задача — неожиданная потребность начать мониторинг вообще всех вызовов — явно из разряда особенных (надуманных).

Эта задача очень часто встречается на практике. Вот буквально неделю назад такая задачка стояла.

V> Решение подобной задачи надо или проектировать вместе с фреймворком,

А если фреймворк уже есть? Только не надо мне рассказывать сказки о том что на этапе проектирования можно предусмотреть все.

V> или потом дорабатывать вообще все и ругать себя за скудоумие.

Или использовать АОП. Такой вариант имхо куда интереснее.

V>Тема крайне интересная, и хотелось бы от IT услышать хоть один достойный пример, где АОП имело бы преимущество перед ООП.

Как тут уже неоднократно замечалось не стоит противопоставлять ООП и АОП. Несмотря на красивые термины АОП ООП это идеология, а АОП всего лишь технология, чаще всего реализуемая при помощи ООП и в его рамках. Не надо сравнивать теплое с мягким.

V>кстати, многое из Remouting в .Net именно на таком уровне и сделано, весьма это далеко от АОП и ООП)

Можно узнать что конкретно в ремоутинге на уровне древнего С?

V>Если не трудно, развития ради, интересно посмотреть на код и оценить трудоемкость подхода IT в решении его собственной задачки. ГВ предложил одну строчку кода на все интересующие методы, трудоемкость в этом случае ясна и понятна. IT, давай решение на АОЯП — справедливости ради, а то пока не ясно как все это сравнивать

А решение на АОП вобще не требует в бизнес-объекте никакого кода. Более того, если АОП фреймворк нормально реализован не требуется даже перекомпиляции для его подключения. Вот например в текущем проекте есть у нас синк, который протоколирует все необработанные исключения сервера. Этот синк не требует никакой поддержки ни со стороны бизнес-кода, ни со стороны прикладного фреймворка, ни со стороны сервера приложений. Одна строчка в конфиге и он работает с любым ремоутинг-сервером. Пока вилла Рибо проектирует фреймворки с поддержкой всех возможных фантазий заказчика и усиленно в очередной раз копипейстит исходники, вилла Баджо давно уже получает с заказчика бабки

Здравствуйте, IT, Вы писали:

IT>>>Не совсем. Классы бизнес логики трогать не надо будет. Этим вообще могут заниматься разные люди и песнях про большие проекты даже разные подразделения.
ГВ>>Ну... не сказал бы, что я предлагаю такие уж сильные изменения в БЛ-классах.
IT>Небольшие изменения тут, небольшие там и вот перед нами каша из логики и вспомогательного кода.
Ну, Игорь, это уже отдаёт пионерством: "эта дорога неверна, мы срочно побежим другой". А чтобы не было каши надо чаще думать, чем работать. Помогает, проверено.

А если без ёрничанья, то перспектива получения каши если не из БЛ+вспомогатльный код, то уж внутри вспомогательного кода или внутри самой БЛ — по любому остаётся.

ГВ>>Зацепили framework — и поехали.
IT>Приципили из BL кода?
Угу, а он всегда с каким-нить окружением связан.

ГВ>>Дальше всё равно по месту смотреть надо, у обоих стратегий есть свои плюсы и минусы.
IT>О! Прогресс на лицо
Ты меня обнадёживаешь.

Здравствуйте, AndrewVK, Вы писали:

V>>(в отличии от CBO, где рефлекшн используется в каждом вызове,

AVK>В MBR (и CBO который ничем от MBR, кроме механики инициации не отличается) рефлекшен не используется. TransparentProxy это и есть то о чем ты говоришь, только реализованое прямо в JIT, т.е. не требующее компиляции вобще, а значит заведомо более быстрое чем то что ты предлагаешь.

Ты знаешь, я никак не могу понять, причем тут TP. Если вы реализуете класс от CBO и он передается между машинами, то это понятно, что скорость TP тут ничего не меняет, так как эта скорость выполнения какается только клиентской машины. Если же этот объект начинает использоваться внутри того домена, где он создан (а сервер скорее всего вызывает методы этого объекта, ибо не просто так же он получает), то скорость TP тут опять не играет. Вся тягость ложится на плечи того, что следует за TP (форматеры, синки, терминаторы и т.д.). И тут, честно говоря, нельзя сходу сказать, что тормозднее — RealProxy или вызов методов через Reflection.

AVK>Тормоза ремоутинга не из-за тормозных проксей, а из за цепочки синков — и формирователи сообщений, и форматтеры и транспортные синки это очень небыстрая операция, поскольку, как правильно заметил IT, механика проксей предназначена не для перехвата вызовов, а для работы ремоутинга.

Именно для перехвата вызовов она и предназначена. А уж как ты распорядишься этими вызовами (транзакции, сериализация, синхронизация, кеширование, безопасность и т.д.) — это твое дело.

AVK>Потому и получается что при вызове через контекст происходит море лишних действий, в том числе и с использованием рефлекшена (для работы форматтера и запуска сообщения).

Ну, не только для форматера. Методы объекта, мне кажется, тоже вызываются через Reflection. Прокся же держит в себе Object.

V>>Ну а теперь вернемся в "человеческое" ООП.
V>>Предложенная задача — неожиданная потребность начать мониторинг вообще всех вызовов — явно из разряда особенных (надуманных).

AVK>Эта задача очень часто встречается на практике. Вот буквально неделю назад такая задачка стояла.

Вообще всех? Ты уверен? Даже внутренние вызова внешних объектов? ИМХО, CBO только ухудшит картину. Часто те объекты, которые передают с сервера на клиент делают сериализуемыми (Serializable) и уж ни как не передают по ссылки.
Или ты предлагаешь идти по такому пути, что на время теста (вряд ли в реальных условиях может пригодиться подсчет вызовов) делать все объекты от CBO, а потом снова переводить их в сериализуемые классы? Тогда явная перекомпиляция + изменение внешнего интерфейса (думаю, не стоит объяснять, что Нет довольно сильно реагирует на изменение базового класса).

Здравствуйте, mikа, Вы писали:

AVK>>В MBR (и CBO который ничем от MBR, кроме механики инициации не отличается) рефлекшен не используется. TransparentProxy это и есть то о чем ты говоришь, только реализованое прямо в JIT, т.е. не требующее компиляции вобще, а значит заведомо более быстрое чем то что ты предлагаешь.

M>Ты знаешь, я никак не могу понять, причем тут TP.

Потому что именно ТР обеспечивает тот функционал, который необходим в АОП. Все остальное это уже инфраструктура ремоутинга, для АОП не нужная.

M> Если вы реализуете класс от CBO и он передается между машинами, то это понятно, что скорость TP тут ничего не меняет, так как эта скорость выполнения какается только клиентской машины. Если же этот объект начинает использоваться внутри того домена, где он создан (а сервер скорее всего вызывает методы этого объекта, ибо не просто так же он получает), то скорость TP тут опять не играет. Вся тягость ложится на плечи того, что следует за TP (форматеры, синки, терминаторы и т.д.).

Все верно, об этом я и писал. Проблема в том что все эти потроха АОП не нужны, а отцепить их от ТР не так то просто (точнее просто, но про автоматическую инициацию придеться забыть).

AVK>>Тормоза ремоутинга не из-за тормозных проксей, а из за цепочки синков — и формирователи сообщений, и форматтеры и транспортные синки это очень небыстрая операция, поскольку, как правильно заметил IT, механика проксей предназначена не для перехвата вызовов, а для работы ремоутинга.

M>Именно для перехвата вызовов она и предназначена.

Вот это новость. Я всегда считал что ремоутинг нужен для передачи объектных сообщений через канал.


AVK>>Потому и получается что при вызове через контекст происходит море лишних действий, в том числе и с использованием рефлекшена (для работы форматтера и запуска сообщения).

M>Ну, не только для форматера. Методы объекта, мне кажется, тоже вызываются через Reflection.

Обрати внимание на выделенное. Это я об RemotingServices.ExecuteMessage().


V>>>Предложенная задача — неожиданная потребность начать мониторинг вообще всех вызовов — явно из разряда особенных (надуманных).

AVK>>Эта задача очень часто встречается на практике. Вот буквально неделю назад такая задачка стояла.

M>Вообще всех? Ты уверен?

Разумеется не вобще всех, а определенной категории.

M> Даже внутренние вызова внешних объектов?

Это да, это как раз и было нужно.

M> ИМХО, CBO только ухудшит картину.

А кто сказал что использовался СВО?

Здравствуйте, AndrewVK, Вы писали:

AVK>Потому что именно ТР обеспечивает тот функционал, который необходим в АОП. Все остальное это уже инфраструктура ремоутинга, для АОП не нужная.

Почему же. ТР помогает только стартовать ремотингу свои АОП-видную инфраструктуру. В С++ нет ТР. Это ведь не значит, что там не может быть АОП.

AVK>Все верно, об этом я и писал. Проблема в том что все эти потроха АОП не нужны, а отцепить их от ТР не так то просто (точнее просто, но про автоматическую инициацию придеться забыть).

Если CAO — то да, а если SAO, то можно что-нибудь сделать с Activator.

AVK>>>Тормоза ремоутинга не из-за тормозных проксей, а из за цепочки синков — и формирователи сообщений, и форматтеры и транспортные синки это очень небыстрая операция, поскольку, как правильно заметил IT, механика проксей предназначена не для перехвата вызовов, а для работы ремоутинга.

M>>Именно для перехвата вызовов она и предназначена.

AVK>Вот это новость. Я всегда считал что ремоутинг нужен для передачи объектных сообщений через канал.

механика проксей предназначена не для перехвата вызовов, а для работы ремоутинга.

Это ты написал? Согласить, высказывание

ремоутинг нужен для передачи объектных сообщений через канал

идет перпендикулярно.

AVK>>>Потому и получается что при вызове через контекст происходит море лишних действий, в том числе и с использованием рефлекшена (для работы форматтера и запуска сообщения).

M>>Ну, не только для форматера. Методы объекта, мне кажется, тоже вызываются через Reflection.

AVK>Обрати внимание на выделенное. Это я об RemotingServices.ExecuteMessage().

Ага. А я дополнил. Нам ведь нужно еще и запустить метод объекта.

M>>Вообще всех? Ты уверен?

AVK>Разумеется не вобще всех, а определенной категории.

Сужаем круг требований. Так глядишь дойдем до того, что это можно было бы предвидеть на этапе проектирования

M>> Даже внутренние вызова внешних объектов?

AVK>Это да, это как раз и было нужно.

Хм. А причем тут тот ремотинг, про который говорил ИТ (ремотинг тут идет в двух ипостясиях: локальный и сетевой). ИТ говорил, что тормоза передачи по сети съедят всю тормознутость, которая получиться от TP + RP. И это правда. А теперь получается, что совсем наоборот. Ничего не будет компенсировать тормоза.

AVK>А кто сказал что использовался СВО?

Транспортная часть (агенты, форматеры, провайдеры, ченелы)? Кстати, это не

внутренние вызова внешних объектов

Может мы по разному понимает фразу "внутренние вызова"?

Здравствуйте, mikа, Вы писали:

M>Почему же. ТР помогает только стартовать ремотингу свои АОП-видную инфраструктуру.

Так то ремоутинг, а мы ведь о чистом АОП говорим. А ему ничего, окромя сладкой парочки TP/RP не нужно. В принципе они вполне живут без остального, но для получения ТР нужно явно сказать RP GetTransparentProxy, а это не есть гуд. Автоматическую же инициацию без врубания ремоутинга целиком сделать не получится.

M> В С++ нет ТР. Это ведь не значит, что там не может быть АОП.

Может, но либо фиговое, либо путем изменения языка (обычно это реализуется препроцессором специальным).

M>Если CAO — то да, а если SAO, то можно что-нибудь сделать с Activator.

Пофигу. Даже СВО все равно подымают и ченел и форматтер. Можно воткнуться до форматтерного синка в ченел и тем самым обойти форматтер, но все равно производительность будет не ахти. Можно еще в мессадж синке вобще до ченнела не допускать, но имхо это уже какой то изврат.

AVK>>Вот это новость. Я всегда считал что ремоутинг нужен для передачи объектных сообщений через канал.

M>

M>механика проксей предназначена не для перехвата вызовов, а для работы ремоутинга.

M>Это ты написал?

Я написал.

M> Согласить, высказывание
M>

M>ремоутинг нужен для передачи объектных сообщений через канал

M>идет перпендикулярно.

Не соглашусь. Вполне соответствует одно другому. Прокся были созданы для работы ремоутинга, но из этого никак не следует что ремоутинг нужен для перехвата вызовов.

AVK>>Обрати внимание на выделенное. Это я об RemotingServices.ExecuteMessage().

M>Ага. А я дополнил. Нам ведь нужно еще и запустить метод объекта.

Блин, Мика, почитай что такое ExecuteMessage и что он делает

AVK>>Разумеется не вобще всех, а определенной категории.

M>Сужаем круг требований. Так глядишь дойдем до того, что это можно было бы предвидеть на этапе проектирования

Нет, не сойдемся. Невозможно предвидеть все возможные требования, на эту тему я даже спорить не буду.

AVK>>Это да, это как раз и было нужно.

M>Хм. А причем тут тот ремотинг, про который говорил ИТ (ремотинг тут идет в двух ипостясиях: локальный и сетевой). ИТ говорил, что тормоза передачи по сети съедят всю тормознутость, которая получиться от TP + RP. И это правда. А теперь получается, что совсем наоборот. Ничего не будет компенсировать тормоза.

При работе ремоутинга будет. При работе АОП нет, поскольку ремоутинг там не нужен и весь оверхед ляжет тяжким грузом на приложение. Т.е. в итоге механика дотнета позволяет строить АО-решения эффективными только для удаленных вызовов.

AVK>>А кто сказал что использовался СВО?

M>Транспортная часть (агенты, форматеры, провайдеры, ченелы)?

Это не имело отношения к той задачке о которой речь. Та задачка была решена написанием банальных проксей, но это не значит что это лучшее решение, просто использовать ремоутинг для трассировки внутрипроцессных вызовов не лучшее решение.

M>

M>внутренние вызова внешних объектов

M>Может мы по разному понимает фразу "внутренние вызова"?

Тебе виднее, ты термин придумал.

Здравствуйте, naje, Вы писали:

N>тем более этот премер я просто атфанаря написал, а ты как всегда к мелачам цепляешься

Разве это мелочи? Во-первых, твой дизайн заставляет разработчика явно вызывать объект через прокси, это ни ясности кода не добавляет, ни защищает от ошибок. Во-вторых, ты посмотри как ты надругался над основами ООП в бизнес классе. Это же больше не ООП, ни инкапсуляции, ни наследования, ни полиморфизма

N>ты лучше ответь на такой вопрос, что если этот заказчик из твоего вопроса захочет не мониторинг добавить, а производительность неимоверную, и/или чтоб програмка вместе с операционкой помещалась на флэшку 8 МБ (такой запрос более реальный чем просьбя о мониторинге), а у тебя всё с испольлванием RealProxy уже написано
N>что делать?

Хороший вопрос между прочим. В случае поддержки AOP самим компилятором, как ты понимаешь, никаких проблем не будет. В случае RealProxy, которую, прошу ещё раз заметить, я не предлагал как панацею, имеем тормоза. Соответственно, придётся извращаться либо предложенным тобой способом, либо как предлагает ГВ.