Re[9]: Спорно.
От: IT Россия linq2db.com
Дата: 23.01.04 13:04
Оценка: 5 (1) +1 :))
Здравствуйте, Геннадий Васильев, Вы писали:

IT>>Ну хотя бы длительность и частоту вызовов.

ГВ>Для каждого метода БЛ? Или для каждого метода, вызываемого клиентским приложением?

Последнее.

IT>>Требование заказчика. Он обчитался пресрелизов от MS и в конце проекта решил добавить мониторинг сервера приложений.

ГВ>Так сервера приложений или бизнес-логики, которая на нём крутится?

Ты будешь пытаться поймать меня на терминалогии или отвечать на вопрос? Если ответить не можешь, то так и скажи "Не разобрался, погорячился, больше не буду". С кем не бывает.
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: Спорно.
От: IT Россия linq2db.com
Дата: 23.01.04 13:13
Оценка: -1 :)))
Здравствуйте, naje, Вы писали:

IT>>Забавно было читать как ты в пух и прах разносил AOP Вот теперь покажи его полную несостоятельность, заменив его своей декомпозицией. Давай, давай.


N>в нормальном фреймворке, с хорошо выделенным уровнем бизнес правил, всё это добавляется без труда на любом этапе, причём без препроцессоров типа AspectX'ов, а примеры таких фреймворков никто приводить я думаю не будет.


Отмазки из серии know-how мы уже тут проходили много раз. Не катит. Know-how нам твои не нужны, ты хотя бы идею озвуч, если она у тебя, конечно, есть.

N>может тебе стоит почитать ещё что-нибудь кроме пресрелизов от ms?


Слушай, дай ссылочку, желательно на английском. Я своим архитекторам из MS и IBM покажу. А то они убогие, ничего кроме RealProxy и атрибутов придумать не могут. А мы им щас опаньки — декомпозиция! И по шапке, и по шапке...
Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: Спорно.
От: naje  
Дата: 23.01.04 13:24
Оценка:
Здравствуйте, IT, Вы писали:

IT>Слушай, дай ссылочку, желательно на английском. Я своим архитекторам из MS и IBM покажу. А то они убогие, ничего кроме RealProxy и атрибутов придумать не могут. А мы им щас опаньки — декомпозиция! И по шапке, и по шапке...


упал, отполз
Re: Спорно.
От: Merle Австрия http://rsdn.ru
Дата: 23.01.04 13:26
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Парадоксально но факт: ничего принципиально нового там нет, всё, что сказано — становилось понятно любому проектировщику ОО-систем ещё эдак лет 10 назад. <...> Ситуация — один в один, как и с паттернами.

<...>

ГВ>Павлов указывает недостатки, которые мне кажутся перефразом очень давно сформулированных тезисов:

ГВ>

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

ГВ>Это можно отнести к любой программе — безотносительно её А- или О- ориентации.
<...>
ГВ>Решалось и решается на уровне проектирования, вернее — декомпозиции. Аспекты, как и объекты — не сами по себе родятся, а только как следствие работы мысли проектировщика.
<...>
ГВ>Проблемы совмещения реализаций аспектов тоже ещё не исследованы и не известны, что отмечает и автор статьи. Кроме того — это же ставилось в вину процедурному подходу.
<...>
ГВ>Именно это ставилось в вину "старому" подходу: структурному проектированию. Не, коллеги, проблема не в ярлыке, который вешается на "методологию", проблема в ДНК проектировщиков.
<...>
ГВ>Проделайте маленький фокус.
<...>
ГВ>Собственно, подобный трюк можно проделать со всей статьёй.

Клева конечно, но с чем ты здесь споришь?
Насколько я понял, автор статьи не объявляет о создании новой серебряной пули, а просто описывает круг проблем, при решении которых AOP облегчает жизнь.
Ты совершенно прав, тоже самое говорили и про процедурное программирование, и точно так же OOP не панацея.
Опять-таки, можно писать афигенски большие программы в чиста-процедурном стиле при наличии правильных рук, все дело в трудозатратах...

ГВ>Ох и любят же апологеты технологий игру словами. Как и я, впрочем. Только я этой игры не скрываю.

Ну вот ты и признался...

ГВ>И опять — "недостатки", на этот раз — подходов к соблюдению контрактов:

ГВ>

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

ГВ>Чушь, извините. Совершенно то же самое можно получить и при бестолковой реализации аспектов. Проблема со свистом обходится глубоой декомпозицией проекта.
Да кто бы спорил, но при AOP эта "глубокая декомпозиция" обходится дешевле.
Ну и так далее...
Вообщем поинт в том, что AOP не универсальное лекарство от всех болезней, как ты, возможно, пытаешься показать, а некая довольно приятная мулька, при наличии которой легче жить.
Мы уже победили, просто это еще не так заметно...
Re[11]: Спорно.
От: mikа Stock#
Дата: 23.01.04 13:49
Оценка:
Здравствуйте, naje, Вы писали:

IT>>Слушай, дай ссылочку, желательно на английском. Я своим архитекторам из MS и IBM покажу. А то они убогие, ничего кроме RealProxy и атрибутов придумать не могут. А мы им щас опаньки — декомпозиция! И по шапке, и по шапке...


N>упал, отполз


А зря. Всего лишь громкие слова, за что он так на Геннадия "наезжал"
Re[12]: Спорно.
От: naje  
Дата: 23.01.04 14:15
Оценка:
Здравствуйте, mikа, Вы писали:

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


IT>>>Слушай, дай ссылочку, желательно на английском. Я своим архитекторам из MS и IBM покажу. А то они убогие, ничего кроме RealProxy и атрибутов придумать не могут. А мы им щас опаньки — декомпозиция! И по шапке, и по шапке...


N>>упал, отполз


M>А зря. Всего лишь громкие слова, за что он так на Геннадия "наезжал"


просто щас если продолжать то флейм про дотнет сюда переедет
хотя причём тут RealProxy до сих пор понять не могу
про атрибуты кстати тоже можно долго спорить
Re[13]: Спорно.
От: mikа Stock#
Дата: 23.01.04 14:19
Оценка:
Здравствуйте, naje, Вы писали:

N>просто щас если продолжать то флейм про дотнет сюда переедет


Надо гнобить.

N>хотя причём тут RealProxy до сих пор понять не могу


В Нете это одна из реализаций аспектной сущности. Хотя, честно говоря, я и сам не понял причем здесь это. Сделать RealProxy через ООП не составит труда. Та же функциональность. Ладно, щас нам Игорь поведует, что же он имел ввиду, кроме понтов

N>про атрибуты кстати тоже можно долго спорить


Пожалуй, это верное решение. Что не посморить-то?
Re[5]: Спорно.
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 23.01.04 14:21
Оценка: 1 (1)
Здравствуйте, <Аноним>, Вы писали:

А>т.б. ты хочешь сказать что АОП это не метод проектирования, а метод добавления?


Очень точно подмечено А проектирование это такое проектирование когда учитывается возможность легкого добавления.
... << RSDN@Home 1.1.3 beta 1 >>
AVK Blog
Re[9]: Спорно.
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 23.01.04 14:21
Оценка: 1 (1) +1
Просьба ограничить объем цитирования.
... << RSDN@Home 1.1.3 beta 1 >>
AVK Blog
Re[12]: Спорно.
От: IT Россия linq2db.com
Дата: 23.01.04 15:27
Оценка: -1 :)
Здравствуйте, mikа, Вы писали:

M>А зря. Всего лишь громкие слова, за что он так на Геннадия "наезжал"


Поясни свою мысль насчёт громких слов, а то пока это выглядит как обвинение во вранье
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: Спорно.
От: IT Россия linq2db.com
Дата: 23.01.04 15:47
Оценка: +1 -1
Здравствуйте, mikа, Вы писали:

N>>хотя причём тут RealProxy до сих пор понять не могу


M>В Нете это одна из реализаций аспектной сущности.


В .NET — это механизм перехвата создания и вызова методов объектов, который можно использовать для имплементации идей AOP, за счёт значительной потери производительности. Но в случае ремоутинга это вполне допустимо.

M>Хотя, честно говоря, я и сам не понял причем здесь это.


При том что задача, которую я поставил перед ГВ вполне решается данным способом.

M>Сделать RealProxy через ООП не составит труда. Та же функциональность.


Ещё один знаток Мика, ну расскажи нам, как сделать RealProxy средствами ООП. Мне правда интересно как на ООП реализуется интерсептор создания объектов, как стэк преобразуется в список параметров и наоборот. И никаких ассемблерных вставок и выкрутасов в стиле C, только чистый ООП.

M>Ладно, щас нам Игорь поведует, что же он имел ввиду, кроме понтов


Да уж, понты так понты. Я хоть за свой базар отвечаю, в отличии от некоторых
Если нам не помогут, то мы тоже никого не пощадим.
Re[15]: Спорно.
От: mikа Stock#
Дата: 23.01.04 16:03
Оценка: 14 (1) -1
Здравствуйте, IT, Вы писали:

IT>В .NET — это механизм перехвата создания и вызова методов объектов, который можно использовать для имплементации идей AOP, за счёт значительной потери производительности. Но в случае ремоутинга это вполне допустимо.


Отлично! У тебя АОП в .NET ассоциируеться только с remoting. Неужели, нет других мест, где он так же реализован, в той или иной мере (даю подсказку, есть )

IT>При том что задача, которую я поставил перед ГВ вполне решается данным способом.


Как и любым другим

M>>Сделать RealProxy через ООП не составит труда. Та же функциональность.


IT>Ещё один знаток Мика, ну расскажи нам, как сделать RealProxy средствами ООП. Мне правда интересно как на ООП реализуется интерсептор создания объектов, как стэк преобразуется в список параметров и наоборот. И никаких ассемблерных вставок и выкрутасов в стиле C, только чистый ООП.


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

IT>Да уж, понты так понты. Я хоть за свой базар отвечаю, в отличии от некоторых


"А пачему сразу Лукашенко!?" (что то юмористическое)
Re[15]: Спорно.
От: naje  
Дата: 23.01.04 16:12
Оценка:
Здравствуйте, IT, Вы писали:

IT>Ещё один знаток Мика, ну расскажи нам, как сделать RealProxy средствами ООП. Мне правда интересно как на ООП реализуется интерсептор создания объектов, как стэк преобразуется в список параметров и наоборот. И никаких ассемблерных вставок и выкрутасов в стиле C, только чистый ООП.


чё-то я опять не догоняю
просто выделяем уровень, как хотим его называем (например уровень бизнес правил), все операции (создание/удаление объекта, вызов методов и т.п.) выполняются через какой-нибудь проксирующий объект (или класс), в котором всё и происходит, хотя тот кто скажет что это не ООП будет наверное прав

Проксирующий объект(или класс) легко поменять (полностью или просто что-то добавить). Причём есть куча методов как это делать тоже не сильно напрягаясь.

Стэк преобразовать в список параметров тоже можно передавая параметры в виде картежа а-ла boost::tuple (хотя реализацию можно и получше придумать, ориентированную просто на передачу параметров), потом я думаю понятно что с ним делать, причём всё это обычные правила программирования на этом верхнем уровне.
Сразу скажу что читабильность программ и производительность не теряется.

А поповоду преоброзовать уже какуюто готовую програмку под этот "верхний уровень", так это на emacs'е пара часов работы(ну может пару дней), хотя зачем это нужно?

И работает даже на всех компиляторах
Re[16]: Спорно.
От: IT Россия linq2db.com
Дата: 23.01.04 16:17
Оценка: +1 -1
Здравствуйте, mikа, Вы писали:

IT>>В .NET — это механизм перехвата создания и вызова методов объектов, который можно использовать для имплементации идей AOP, за счёт значительной потери производительности. Но в случае ремоутинга это вполне допустимо.


M>Отлично! У тебя АОП в .NET ассоциируеться только с remoting. Неужели, нет других мест, где он так же реализован, в той или иной мере (даю подсказку, есть )


Почитай, что я выше написал, особенно выделенное.

IT>>При том что задача, которую я поставил перед ГВ вполне решается данным способом.


M>Как и любым другим


Ну хоть один другой отличный от данного покажи

IT>>Ещё один знаток Мика, ну расскажи нам, как сделать RealProxy средствами ООП. Мне правда интересно как на ООП реализуется интерсептор создания объектов, как стэк преобразуется в список параметров и наоборот. И никаких ассемблерных вставок и выкрутасов в стиле C, только чистый ООП.


M>Я прям стою и падаю. Такое чувство, что отнаследнование от ContextBountObject это не ООП.

M>Ты же в самом начале это делаешь. И именно, сделав аналог для ООП, можно добиться тех же результатов, что и для АОП.

Ты только не путай тёплое с мягким. Наследование от CBO, для которого уже реализован RealProxy и реализация RealProxy средствами ООП это далеко не одно и тоже.
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: Спорно.
От: IT Россия linq2db.com
Дата: 23.01.04 16:27
Оценка:
Здравствуйте, naje, Вы писали:

N>просто выделяем уровень, как хотим его называем (например уровень бизнес правил), все операции (создание/удаление объекта, вызов методов и т.п.) выполняются через какой-нибудь проксирующий объект (или класс), в котором всё и происходит, хотя тот кто скажет что это не ООП будет наверное прав


N>Проксирующий объект(или класс) легко поменять (полностью или просто что-то добавить). Причём есть куча методов как это делать тоже не сильно напрягаясь.


N>Стэк преобразовать в список параметров тоже можно передавая параметры в виде картежа а-ла boost::tuple (хотя реализацию можно и получше придумать, ориентированную просто на передачу параметров), потом я думаю понятно что с ним делать, причём всё это обычные правила программирования на этом верхнем уровне.

N>Сразу скажу что читабильность программ и производительность не теряется.

Хорошо бы кусочек кода самого класса, его прокси и вызывающего метода. Тонкости реализации не нужны, но на то как это может использоваться посмотреть очень даже интересно.
Если нам не помогут, то мы тоже никого не пощадим.
Re[17]: Спорно.
От: naje  
Дата: 23.01.04 17:37
Оценка:
Здравствуйте, IT, Вы писали:

IT>Хорошо бы кусочек кода самого класса, его прокси и вызывающего метода. Тонкости реализации не нужны, но на то как это может использоваться посмотреть очень даже интересно.




struct MyClass
{
    struct Action1
    {
        typedef int ret;
        template<typename P>
        static int Do(MyClass& This, const P& p)
        {
            Get<1>(p);
                // доступ к параметру по индексу
            Get<xParam>(p);
                // доступ по как-нибудь ассоциированному типу (xParam - какой-то уникальный тип)
            ForEach(p,SomeFunctor()); //просто перечисляем все параметры
        }
    };
    struct Action2
    {
        template<typename P>
        static int Do(MyClass& This, const P& p)
        {
        }
    };
};

// можно специализировать для любого действия и для любого класа статически
// + дефолтавая реализация может подобрать что-то в rt
template<typename T, typename A>
struct ProxyHlpr
{
    typedef typename A::ret ret;
    template<typename P>
    static void after(T& t, const P& p)
    {
    }
    template<typename P>
    static void before(T& t, const P& p)
    {
    }
    template<typename P>
    static ret call(MyClass& t, const P& p)
    {
        return MyClass::Action1::Do(t,p);
    }
};


template<typename O>
struct UnrealProxy
{
private:
    O obj;
public:
    UnrealProxy():obj(){}
    template<typename T, typename P>
    typename ProxyHlpr<O,T>::ret Do(const P& p)
    {
        ProxyHlpr<O,T>::before(obj,p);
        ProxyHlpr<O,T>::ret ret=ProxyHlpr<O,T>::call(obj,p);
        ProxyHlpr<O,T>::after(obj,p);
    }
};

...........................

//а это уже более высокий уровень

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


+ всё это можно приправить всякими рюшечками типа переопределеных операторов [],(),->, более удачных названий, генерации структур Action1 по обычным методам класса(правда перечисл. в каком-нибудь листе типов), то что делает ProxyHlpr можно разнести в разные классы, чтоб удобней специализировать было, специализировать его можно не по класу и действию, а по групе класов и действий, ну и куча других приёмчиков, которые к этому топику отношения не имеют
Re[17]: Спорно.
От: mikа Stock#
Дата: 24.01.04 13:30
Оценка:
Здравствуйте, IT, Вы писали:

IT>>>В .NET — это механизм перехвата создания и вызова методов объектов, который можно использовать для имплементации идей AOP, за счёт значительной потери производительности. Но в случае ремоутинга это вполне допустимо.


...

IT>Почитай, что я выше написал, особенно выделенное.


Интересно, а причем здесь АОП? Я конечно понимаю, что тормоза, погода, красный цвет — это все у тебя к стилю программирования относиться

Ладно, ты сейчас очень хочешь уйти от темы, вернее, от той задачи которую ты поставил. Я попробую тебе этому воспрепятствовать.

И так, есть уже готовая система, в которой нужно для бизнес-объектов сделать подсчет вызовов методов. Так?

Чем тут потожет АОП? Да ничем, если изначально мы не сделали для нее фундамент из контекстов! Чисто гипотетически, мы это сделали заранее. Теперь, нам нужно лишь сделать реализацию RealProxy и все дела.

Ага. Щаз! Только вот те тормоза, которые при этом возникают, это не в счет. Конечно, зачем их учитывать, если мы программируем с использованием АОП.

И не надо спихивать на тормознутость ремотинга (он очень шустр), с бизнес-сущностями мы может работать и не через границы домена (а часто так и делаем. Мы работаем через специализированные провайдеры, где как раз и можно вести учет вызовов). Это будет полным бредом, чтобы задейстовавать инфраструктуру удаленного взаимодействия в локально исполняющейся программе.

Ладно. Теперь перейдем к метапрограмированию. Атрибуты — это хорошо. Очень хорошо. Но! Только тогда, когда они в меру и когда они реально нужны. Или для тебя Reflection ничего не значит, вернее его производительность?

Гремучая смесь из ремотинга и позднего связывания в одном потоке, по-моему это уж слишком.

IT>Ты только не путай тёплое с мягким. Наследование от CBO, для которого уже реализован RealProxy и реализация RealProxy средствами ООП это далеко не одно и тоже.


Во-первых, RealProxy в .NET реализован средствами ООП. Это к тому, кто тут путает теплое с мягким.
Во-вторых, смотри выше в моем ответе про провайдеры.
Re[18]: Спорно.
От: IT Россия linq2db.com
Дата: 24.01.04 21:21
Оценка:
Здравствуйте, mikа, Вы писали:

IT>>Почитай, что я выше написал, особенно выделенное.


M>Интересно, а причем здесь АОП? Я конечно понимаю, что тормоза, погода, красный цвет — это все у тебя к стилю программирования относиться


Чего? Видимо тебе не лишним будет перечитать не только моё, но и своё сообщение Ты хоть сам понял что написал?

M>Ладно, ты сейчас очень хочешь уйти от темы, вернее, от той задачи которую ты поставил. Я попробую тебе этому воспрепятствовать.


Мда, плохому ты быстро учишься

M>И так, есть уже готовая система, в которой нужно для бизнес-объектов сделать подсчет вызовов методов. Так?


Точно, молодец!

M>Чем тут потожет АОП? Да ничем, если изначально мы не сделали для нее фундамент из контекстов! Чисто гипотетически, мы это сделали заранее. Теперь, нам нужно лишь сделать реализацию RealProxy и все дела.


M>Ага. Щаз! Только вот те тормоза, которые при этом возникают, это не в счет. Конечно, зачем их учитывать, если мы программируем с использованием АОП.


Опять не вижу логики

M>И не надо спихивать на тормознутость ремотинга (он очень шустр), с бизнес-сущностями мы может работать и не через границы домена (а часто так и делаем. Мы работаем через специализированные провайдеры, где как раз и можно вести учет вызовов). Это будет полным бредом, чтобы задейстовавать инфраструктуру удаленного взаимодействия в локально исполняющейся программе.


Теперь я понял, ты разговариваешь сам с собой и додумываешь за меня то, чего не понял. Ok, ещё раз для особо одарённых. Вот то, к чему ты решил докопаться:

N>>>хотя причём тут RealProxy до сих пор понять не могу

M>>В Нете это одна из реализаций аспектной сущности.

IT>В .NET — это механизм перехвата создания и вызова методов объектов, который можно использовать для имплементации идей AOP, за счёт значительной потери производительности. Но в случае ремоутинга это вполне допустимо.


Механизм TransparentProxy/RealProxy в .NET это не реализация аспектной сущности. Это такая штука, которую можно приспособить для динамической интеграции аспектов, но её основное назначение совсем другое. Сделать это можно только, если твой объект наследник CBO либо MBR + используется ремоутинг, хотя в последнем случае RealProxy тоже врядли прокатит. Потеря производительности на вызовах методов в данном случае будет весьма ощутимая, но в случае ремоутинга это не страшно, т.к. TransparentProxy всё равно создаётся для объекта, т.е. у нас просто нет выбора. Таким образом, этот механизм можно использовать для имплементации идей AOP, за счёт значительной потери производительности. Но в случае ремоутинга это вполне допустимо.

Теперь мысль ясна?

M>Ладно. Теперь перейдем к метапрограмированию. Атрибуты — это хорошо. Очень хорошо. Но! Только тогда, когда они в меру и когда они реально нужны. Или для тебя Reflection ничего не значит, вернее его производительность?


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

M>Гремучая смесь из ремотинга и позднего связывания в одном потоке,


Да хоть в двух потоках, какая разница? Или ты имел ввиду домены?

M>по-моему это уж слишком.


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

IT>>Ты только не путай тёплое с мягким. Наследование от CBO, для которого уже реализован RealProxy и реализация RealProxy средствами ООП это далеко не одно и тоже.


M>Во-первых, RealProxy в .NET реализован средствами ООП. Это к тому, кто тут путает теплое с мягким.


Ну покажи мне в Роторе то место где создаётся и вызывается RealProxy средствами ООП.
Хотя, не стоит тратить время, лучше почитай матчасть, особенно про то, что такое TransparentProxy?
Если нам не помогут, то мы тоже никого не пощадим.
Re[19]: Спорно.
От: mikа Stock#
Дата: 24.01.04 21:59
Оценка:
Здравствуйте, IT, Вы писали:

IT>Теперь я понял, ты разговариваешь сам с собой и додумываешь за меня то, чего не понял. Ok, ещё раз для особо одарённых.


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

IT>Механизм TransparentProxy/RealProxy в .NET это не реализация аспектной сущности. Это такая штука, которую можно приспособить для динамической интеграции аспектов, но её основное назначение совсем другое. Сделать это можно только, если твой объект наследник CBO либо MBR + используется ремоутинг, хотя в последнем случае RealProxy тоже врядли прокатит. Потеря производительности на вызовах методов в данном случае будет весьма ощутимая, но в случае ремоутинга это не страшно, т.к. TransparentProxy всё равно создаётся для объекта, т.е. у нас просто нет выбора. Таким образом, этот механизм можно использовать для имплементации идей AOP, за счёт значительной потери производительности. Но в случае ремоутинга это вполне допустимо.


IT>Теперь мысль ясна?


Спасибо, что разяснил. А то я не знал. Только, скорее всего, это ты сам с собою тут общаешся.

Идем к исходной твоей задаче, подсчет вызовов.

Система в эксплуатации и вполне функционирует. Решили добавить к ней твое требование.

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

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

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


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

M>>Гремучая смесь из ремотинга и позднего связывания в одном потоке,


IT>Да хоть в двух потоках, какая разница? Или ты имел ввиду домены?


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

M>>Во-первых, RealProxy в .NET реализован средствами ООП. Это к тому, кто тут путает теплое с мягким.


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


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

IT>Хотя, не стоит тратить время, лучше почитай матчасть, особенно про то, что такое TransparentProxy?


Обязательно, Игорь. Сам тебе хотел посоветовать, да вот потом решил, что рыбные места выдавать ни к чему.
Re[18]: Спорно.
От: IT Россия linq2db.com
Дата: 24.01.04 22:55
Оценка: :)
Здравствуйте, naje, Вы писали:

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


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

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


Очень наглядно. Хотя, конечно, в качестве job security очень даже ничего
Если нам не помогут, то мы тоже никого не пощадим.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.