MC>Я так понял спорит бесполезно, я щас в сотый раз обьясню почему сделано так, а вы сотый раз это проигнорируете и покажите еще один из десятков возможных реализаций. Вы хоть попробовали пропаблишить? Ну хоть чтото попробовать из того что я приводил в качесте пирмеров. Вобщемто поговорили, я так понимаю сотый раз не нужен...
Ветка показывает что вас не понимает как минимум два человека.
MC>>>Нетипизирована, потому что кроме обьектов могут создаваться странички, темы, скины, ваши кастомные что-то. IB>>Это все тоже объекты, но дело не в этом. Мне непонятно, почему сначала не была сделана типизированная фабрика для всех объектов, которые можно задать типизировано, а уже поверх этого сделать нетипизированный механизм для пользования из aspx?
MC>Я уже дисяток раз обьяснил почему она нетипизирована. Вы же не типизируете урлы. Так и тут это просто опиматель обьекта.
Есть библиотека которая как раз типизирует query string, очень удобно.
Здравствуйте, Mike Chaliy, Вы писали:
MC>Туда-туда. Есть маштабируемость приложений. Есть большое количество аджакс кода. Есть сотояния страницы в которых отсутвует необходимость ссылок на Апп_Коде и соответвенно ее подгрузки в домен. И именно нетипизрованный ОДС это лучше всего потдерживает.
Может вы считаете, что для каждой страницы создается отдельный домен приложения? Иначе я совсем не могу понять причем тут масштабируемость и тем более аякс.
He's taking the preventive measures, It must have been too late
Здравствуйте, Sacode, Вы писали:
S>Здравствуйте, Mike Chaliy, Вы писали:
MC>>>>Еще раз. При использовании интрфейсов в коде страницы они в месте с Апп_Коде будут подгружены в домен приложения. Если ссылок на эти интерфейсы в странице небудет. То ничего никуда пожгружаться не будет.
S>>>Не понимаю, в чем проблема "подгрузки интерфейсов"? Также не совсем понимаю при чем тут App_Code вообще. S>>>Что-то вы куда-то не тудв уже ушли. Какое это все имеет отношение к ODS,
MC>>Туда-туда. Есть маштабируемость приложений. Есть большое количество аджакс кода. Есть сотояния страницы в которых отсутвует необходимость ссылок на Апп_Коде и соответвенно ее подгрузки в домен. И именно нетипизрованный ОДС это лучше всего потдерживает.
S>Сборка загружается в домен один раз, и занимает там свои условные 50 килобайт. Не понимаю в чем проблема один раз за несколько месяцев работы приложения потратить доли секунды и 50Кб на загрузку в домен еще одно сборки?! Кстати, ты представляешь сколько сборок так уже загружено? S>К тому же твой ODS в конце концов все равно загрузит сборку, только возможно в другое время, вот и вся разница.
Когда понадобиться загрузит. Разница в том что когда ты это отдаеш на откуп инраструктуре, ты добовляеш возможностей. Добовляеш машатбируемость. Например, как сказал Gollum можно настроить компиляцию так штобы каждая подпапка компилилась в свою сборку. Это обозначает что мы еще уменьшем загрузку за счет того что будут подгружаться меньшие части. И так далее. Ты же мне сам сказал про то что я больших сайтов не делал... Так зачем ты в свое сайте делаеш затык? Это мелочь. Но тут мелочь, там мелочь и странички грузяться по полтора часа. Ваши игрушки с умными патернами тому очень даже способствуют.
MC>>Проблемы вообще коментировать не буду.
S>Почему? Это же и есть основная тема спора.
Пусть живет флейм: S> 1. Нетипизирован — следовательно нет контроля за всеми этими строками и пр. кухней со стороны компилятора. Как следствие меняем название класса/метода, все компилируется, но не работает. Не говоря уже про написанную невозможность Find Usages.
Чепуха. Про то что меняем название класса, еще большая чепуха. А ечли вы поменяли название страницы? Эта ошибка отлавливаеться при первом же прогоне чек листа. Ессно если вы ее не контролируете. У меня таких проблем пока небыло. Find Usages — Ctrl+F. Вы же не перживаете что Find Usages неработает для поиска ссылок на страницу.
2. Он контрол, т.е. обязательно требует наличия страницы ASPX. Использование паттерна MVC/MVP вызывает определенные трудности.
Есто естесвенно, это же ситема биндинга для асп.нет. У ВинФорм есть своя. У ВПФ тоже. Это полностю отличающиеся технологии. Не имеет смыла шарить между ними биндинг.
3. Производительность. ODS из-за своей нетипизированности внутри использует Reflection. Не самая быстрая вещь...
Для компиляции страниц используеться все тоже. Но тут то и фитча что когджа вы отдает это все на откуп системе то именно система следит за скоростю. Про то почему это хорошо смотри та где я упомянул слово маштабируемость.
4. То, как у него задаются параметры методов — это вообще темя садо-мазо. Для того чтобы передать в метод значение свойства страницы надо делать кульбит с ControlParameter.
Попробуй указать DefaultValue.
А вообщето если хочеться использовать к одебехаинде, и раз вы уже собрались тут писать свою реализацию. То просто унаследуйтесь от Parameter и сделаете удобную вам реализацию.
G>Давайте по-другому. Я так понимаю, что речь идет о недоступности типа из App_Code в какой-то момент времени. Напишите когда я не смогу им пользоваться, я приведу контр-пример.
Речь не идет о недоступности. Билдер асп.нета нормально дуплиться и свободно это менеджет. Попробую еще раз обьяснить.
Когда сайт паблишеться. Каждая страница компилиться в отдельную сборку(если ничего не менять в настройках).
а) Далее если в коде страницы есть ссылка на тип(интерфейс, пофику) например из Апп_Коде, то компилятор страницы автоматически добавить рефренс на эту либу. Когда страница будет уже компилиться в исполняемы код, эта либа подгрузиться.
б) В коде страницы нет ссылки на тип из например Апп_Коде. В скомпилиной сборке не будет референса на Апп_Коде. Соответвенно когда клас страницы бедет выполняться ничего подгружатбься не будет. Теперь когда ОДС понядобиться(если понядобиться) он обратиться к BuildManager и все что ему надо получит.
Здравствуйте, Gollum, Вы писали:
MC>>Я так понял спорит бесполезно, я щас в сотый раз обьясню почему сделано так, а вы сотый раз это проигнорируете и покажите еще один из десятков возможных реализаций. Вы хоть попробовали пропаблишить? Ну хоть чтото попробовать из того что я приводил в качесте пирмеров. Вобщемто поговорили, я так понимаю сотый раз не нужен...
G>Ветка показывает что вас не понимает как минимум два человека.
+1!
MC>>>>Нетипизирована, потому что кроме обьектов могут создаваться странички, темы, скины, ваши кастомные что-то. IB>>>Это все тоже объекты, но дело не в этом. Мне непонятно, почему сначала не была сделана типизированная фабрика для всех объектов, которые можно задать типизировано, а уже поверх этого сделать нетипизированный механизм для пользования из aspx?
MC>>Я уже дисяток раз обьяснил почему она нетипизирована. Вы же не типизируете урлы. Так и тут это просто опиматель обьекта. G>Есть библиотека которая как раз типизирует query string, очень удобно.
Более того у меня в проекте, без всякой библиотеки все параметры страницы, будь то QuesryString или еще какие выведены в свойства, естественно все типизировано.
По-моему всем участникам разговора понятно зачем нужна типизация. Кроме одного...
Здравствуйте, Gollum, Вы писали:
G>Здравствуйте, Mike Chaliy, Вы писали:
G>Ветка показывает что вас не понимает как минимум два человека.
В этом нет ничего сташного. Што вам што мне всерано. Жаль что никто не получил новой инфы.
G>Есть библиотека которая как раз типизирует query string, очень удобно.
Ндя. Вы с HyperLink никогда не сталкивались? Ну или просто тегом a. Че вы там на типизируете?
Здравствуйте, Mike Chaliy, Вы писали:
MC>Здравствуйте, Sacode, Вы писали:
MC>>>>>Еще раз. При использовании интрфейсов в коде страницы они в месте с Апп_Коде будут подгружены в домен приложения. Если ссылок на эти интерфейсы в странице небудет. То ничего никуда пожгружаться не будет.
S>>>>Не понимаю, в чем проблема "подгрузки интерфейсов"? Также не совсем понимаю при чем тут App_Code вообще. S>>>>Что-то вы куда-то не тудв уже ушли. Какое это все имеет отношение к ODS,
MC>>>Туда-туда. Есть маштабируемость приложений. Есть большое количество аджакс кода. Есть сотояния страницы в которых отсутвует необходимость ссылок на Апп_Коде и соответвенно ее подгрузки в домен. И именно нетипизрованный ОДС это лучше всего потдерживает.
S>>Сборка загружается в домен один раз, и занимает там свои условные 50 килобайт. Не понимаю в чем проблема один раз за несколько месяцев работы приложения потратить доли секунды и 50Кб на загрузку в домен еще одно сборки?! Кстати, ты представляешь сколько сборок так уже загружено? S>>К тому же твой ODS в конце концов все равно загрузит сборку, только возможно в другое время, вот и вся разница.
MC>Когда понадобиться загрузит. Разница в том что когда ты это отдаеш на откуп инраструктуре, ты добовляеш возможностей.
Каких возможностей можно при этом добавить?
MC>Добовляеш машатбируемость.
Тем что экономлю 50 Кб памяти и доли секунды один раз в несколько месяцев?!
MC>Например, как сказал Gollum можно настроить компиляцию так штобы каждая подпапка компилилась в свою сборку. Это обозначает что мы еще уменьшем загрузку за счет того что будут подгружаться меньшие части. И так далее. Ты же мне сам сказал про то что я больших сайтов не делал... Так зачем ты в свое сайте делаеш затык? Это мелочь. Но тут мелочь, там мелочь и странички грузяться по полтора часа. Ваши игрушки с умными патернами тому очень даже способствуют.
Если мелочь экономит нам 1 секунду, и при этом используется миллион раз за день — это одно, а если она нам экономит 1 секунду один раз в месяц — это "борьба с ветряными мельницами".
MC>>>Проблемы вообще коментировать не буду. S>>Почему? Это же и есть основная тема спора. MC>Пусть живет флейм: S>> 1. Нетипизирован — следовательно нет контроля за всеми этими строками и пр. кухней со стороны компилятора. Как следствие меняем название класса/метода, все компилируется, но не работает. Не говоря уже про написанную невозможность Find Usages.
MC>Чепуха. Про то что меняем название класса, еще большая чепуха.
Весомый аргумент, даже не поспоришь...
MC>А ечли вы поменяли название страницы? Эта ошибка отлавливаеться при первом же прогоне чек листа. Ессно если вы ее не контролируете. У меня таких проблем пока небыло.
А при чем тут название страницы? А ошибка должна отлавливаться не при прогоне, а при компиляции, не говоря уже о том, что если пользоваться средствами рефакторинга, то такой ошибки вообще быть не должно при типизированном ODS.
MC>Find Usages — Ctrl+F. Вы же не перживаете что Find Usages неработает для поиска ссылок на страницу.
Я как раз переживаю. Я использую инструмент ReSharper для рефайторинга кода, и в случае с ODS он не работает. А некоторые методы я переименовывал по 5 раз, и переносил их в другие пространства имен и даже классы.
S>>2. Он контрол, т.е. обязательно требует наличия страницы ASPX. Использование паттерна MVC/MVP вызывает определенные трудности.
MC>Есто естесвенно, это же ситема биндинга для асп.нет. У ВинФорм есть своя. У ВПФ тоже. Это полностю отличающиеся технологии. Не имеет смыла шарить между ними биндинг.
Я считаю, что очень даже имеет.
MC>3. Производительность. ODS из-за своей нетипизированности внутри использует Reflection. Не самая быстрая вещь...
MC>Для компиляции страниц используеться все тоже. Но тут то и фитча что когджа вы отдает это все на откуп системе то именно система следит за скоростю. Про то почему это хорошо смотри та где я упомянул слово маштабируемость.
Как система следит за скоростью? Можно подробней?
MC>4. То, как у него задаются параметры методов — это вообще темя садо-мазо. Для того чтобы передать в метод значение свойства страницы надо делать кульбит с ControlParameter.
MC>Попробуй указать DefaultValue.
Байндинг для параметров не работает, а мне нужно чтобы значение параметра бралось из свойства страницы. В случае с ODS приходиться писать присвоение значения параметру в код-бихайнд, что автоматически нивилирует то, что он контрол и с ним удобно работать в дизайнере. Хотя есть обходной путь, без код-бихайнда, но не всякий его знает.
MC>А вообщето если хочеться использовать к одебехаинде, и раз вы уже собрались тут писать свою реализацию. То просто унаследуйтесь от Parameter и сделаете удобную вам реализацию.
Проще написать свой ODS, чем исправлять все его косяки.
MC>5. Еще? MC>Давай еще.
При операции изменения объекта тот объект, который передается в конечном счете моему методу (UpdateEntity(Entity updatedEntity)) через ODS не содержит значения полей, которые не изменялись и не присутствовали в списке ключевых. Значения этих полей или null, или значения по-умолчанию. Хотя это косяк больше наверное относиться не конкретно к ODS, а к механизму байндинга в целом.
Здравствуйте, Sacode, Вы писали:
MC>>Добовляеш машатбируемость.
S>Тем что экономлю 50 Кб памяти и доли секунды один раз в несколько месяцев?!
Ндя. Мы так мы всетаки горим прос домашние странички?
MC>>Например, как сказал Gollum можно настроить компиляцию так штобы каждая подпапка компилилась в свою сборку. Это обозначает что мы еще уменьшем загрузку за счет того что будут подгружаться меньшие части. И так далее. Ты же мне сам сказал про то что я больших сайтов не делал... Так зачем ты в свое сайте делаеш затык? Это мелочь. Но тут мелочь, там мелочь и странички грузяться по полтора часа. Ваши игрушки с умными патернами тому очень даже способствуют.
S>Если мелочь экономит нам 1 секунду, и при этом используется миллион раз за день — это одно, а если она нам экономит 1 секунду один раз в месяц — это "борьба с ветряными мельницами".
Борьба с ветряными мельбницами, это попытка использование системы не так как она задизайнерена (по налагии драться не стем что для того предназаначено, саому себе ставить трудности и их решать. Такой подход обычно никогда не имеет успеха. Хотя клиентам потом можно втирать про то что вот у меня супер система. Использет МВП. Клиенты просто писать паром будут.
MC>>А ечли вы поменяли название страницы? Эта ошибка отлавливаеться при первом же прогоне чек листа. Ессно если вы ее не контролируете. У меня таких проблем пока небыло.
S>А при чем тут название страницы? А ошибка должна отлавливаться не при прогоне, а при компиляции, не говоря уже о том, что если пользоваться средствами рефакторинга, то такой ошибки вообще быть не должно при типизированном ODS.
При том что если ты поменяеш название страницы. ТО эту ошибку ты тоже не отловиш при компиляции. Если ты поменяеш название класса в дажваскрипте и там не отловиш. Вобщемто я не вижу в этом проблемы. Поэтому и чепуха. Да решарпером удобно поменять названия всех класов. Ну и што. Вы же сами сказали что пишете супер большие сайты. И че так прямо автоматом и делаете замены? А потом обьясняете всей команде и ПМ зачем вы расчекаутили полторы тысячи файлов? Или у вас дизайн спеки нема? Хорошо же вы там свои болльшие сайты педалите.
MC>>Find Usages — Ctrl+F. Вы же не перживаете что Find Usages неработает для поиска ссылок на страницу.
S>Я как раз переживаю. Я использую инструмент ReSharper для рефайторинга кода, и в случае с ODS он не работает. А некоторые методы я переименовывал по 5 раз, и переносил их в другие пространства имен и даже классы.
Читай выше. В утевержденной спеке менять методы. Гыгы. Или опять пишем домашнюю страничку?
S>>>2. Он контрол, т.е. обязательно требует наличия страницы ASPX. Использование паттерна MVC/MVP вызывает определенные трудности.
MC>>Есто естесвенно, это же ситема биндинга для асп.нет. У ВинФорм есть своя. У ВПФ тоже. Это полностю отличающиеся технологии. Не имеет смыла шарить между ними биндинг. S>Я считаю, что очень даже имеет.
Гениально. И как вы собираетесь в асп.нете сделать так чтобы динамически все рефрешилось? Нафика пейджинг и тем более размер страницы в ВинФормах? Нафига вообще все эти заморочи в ВПФ? Таких зачем милион.
S>Как система следит за скоростью? Можно подробней?
Кеши. Прекомпилы. Прелоады. Выгрзки ненужного. Все что угодо.
S>Байндинг для параметров не работает, а мне нужно чтобы значение параметра бралось из свойства страницы. В случае с ODS приходиться писать присвоение значения параметру в код-бихайнд, что автоматически нивилирует то, что он контрол и с ним удобно работать в дизайнере. Хотя есть обходной путь, без код-бихайнда, но не всякий его знает.
Ну так и че за проблемы написать свой? Это же БАЗОВАЯ билиотека. Вы же себе придумали проблему. Вот и решайте.
S>При операции изменения объекта тот объект, который передается в конечном счете моему методу (UpdateEntity(Entity updatedEntity)) через ODS не содержит значения полей, которые не изменялись и не присутствовали в списке ключевых. Значения этих полей или null, или значения по-умолчанию. Хотя это косяк больше наверное относиться не конкретно к ODS, а к механизму байндинга в целом.
Разве в евенте нет это инфы? Цеплятесь делайте что хотите.
Здравствуйте, Mike Chaliy, Вы писали:
MC>Когда сайт паблишеться. Каждая страница компилиться в отдельную сборку(если ничего не менять в настройках). MC>а) Далее если в коде страницы есть ссылка на тип(интерфейс, пофику) например из Апп_Коде, то компилятор страницы автоматически добавить рефренс на эту либу. Когда страница будет уже компилиться в исполняемы код, эта либа подгрузиться.
MC>б) В коде страницы нет ссылки на тип из например Апп_Коде. В скомпилиной сборке не будет референса на Апп_Коде. Соответвенно когда клас страницы бедет выполняться ничего подгружатбься не будет. Теперь когда ОДС понядобиться(если понядобиться) он обратиться к BuildManager и все что ему надо получит.
Судя по декомпиляции ODS и BuildManager'а все сборки подгружаются по первому требованию любого. Это первое требование приходит гораздо раньше, чем начинает работать ODS.
Так что разницы никакой, за исключением того, что BuildManager может найти больше одного класса с указанным в ODS именем, и тогда:
throw new HttpException(SR.GetString("Ambiguous_type", new object[] { typeName, Util.GetAssemblySafePathFromType(type1), Util.GetAssemblySafePathFromType(type2) }));
Здравствуйте, Sacode, Вы писали:
S>Судя по декомпиляции ODS и BuildManager'а все сборки подгружаются по первому требованию любого. Это первое требование приходит гораздо раньше, чем начинает работать ODS. S>Так что разницы никакой, за исключением того, что BuildManager может найти больше одного класса с указанным в ODS именем, и тогда: S>
S>throw new HttpException(SR.GetString("Ambiguous_type", new object[] { typeName, Util.GetAssemblySafePathFromType(type1), Util.GetAssemblySafePathFromType(type2) }));
S>
S>
Ткните пальчиком где они загружаються. Все сборки тока компиляться по первому требованию. Gollum уже это говрил. Для любителей полазить внутри надо искать метод EnsureTopLevelFilesCompiled. А подгружаються они по правилам дотНета.
Здравствуйте, Mike Chaliy, Вы писали:
MC>>>Добовляеш машатбируемость. S>>Тем что экономлю 50 Кб памяти и доли секунды один раз в несколько месяцев?! MC>Ндя. Мы так мы всетаки горим прос домашние странички?
У нас на сервере 6 Гб памяти, нас 50 килобайт не волнуют. К тому же смотри мой пост про BuildManager, 50 Кб все равно съедаются.
S>>А при чем тут название страницы? А ошибка должна отлавливаться не при прогоне, а при компиляции, не говоря уже о том, что если пользоваться средствами рефакторинга, то такой ошибки вообще быть не должно при типизированном ODS. MC>При том что если ты поменяеш название страницы. ТО эту ошибку ты тоже не отловиш при компиляции. Если ты поменяеш название класса в дажваскрипте и там не отловиш. Вобщемто я не вижу в этом проблемы. Поэтому и чепуха.
Это проблема, просто ее еще не решили.
MC>Да решарпером удобно поменять названия всех класов. Ну и што. Вы же сами сказали что пишете супер большие сайты. И че так прямо автоматом и делаете замены?
Ни дня без переименования чего-либо. Серьезно. Если есть ReSharper, это проходит без проблем. Это не означает, что я каждый день меняю интерфейсы, или спецификации, хотя и их тоже меняем.
MC>А потом обьясняете всей команде и ПМ зачем вы расчекаутили полторы тысячи файлов? Или у вас дизайн спеки нема? Хорошо же вы там свои болльшие сайты педалите.
У нас неэксклюзивный чекаут. Объяснять ничего не надо, это пишется в комментарии к чекину. Если есть такая необходимость — поменять спецификации не проблема.
MC>>>Find Usages — Ctrl+F. Вы же не перживаете что Find Usages неработает для поиска ссылок на страницу. S>>Я как раз переживаю. Я использую инструмент ReSharper для рефайторинга кода, и в случае с ODS он не работает. А некоторые методы я переименовывал по 5 раз, и переносил их в другие пространства имен и даже классы.
MC>Читай выше. В утевержденной спеке менять методы. Гыгы. Или опять пишем домашнюю страничку?
Мы используем SOA и Agile (MSF for Agile). Контракты веб-сервисов меняются часто пока пишутся, потом создаются новые версии. Утвержденной спеки во время разработки у нас нет, она появляется после альфа, или даже бета версии (т.е. когда появляются зависимости других проектов от нее). Спецификации, контракты, интерфейсы, схемы БД — это обыкновенный продукт разработки и как и другие продукты разработки изменяется во время разработки. Это наш случай. Есть случаи, когда спецификация оговаривается заранее, но слепо ей следовать до конца, при наличии явных проблем — глупо. Поэтому любые спецификации меняются, меняются названия, и как следствие — проблемы.
MC>Гениально. И как вы собираетесь в асп.нете сделать так чтобы динамически все рефрешилось? Нафика пейджинг и тем более размер страницы в ВинФормах? Нафига вообще все эти заморочи в ВПФ? Таких зачем милион.
Как раз MVP/MVC — это пример как это можно, и нужно делать. А пейджинг в WinForms тоже нужен, ну или подгрузка данных, если угодно.
S>>Как система следит за скоростью? Можно подробней?
MC>Кеши. Прекомпилы. Прелоады. Выгрзки ненужного. Все что угодо.
Кеши чего? Прекомпилы? Уже все скомпилировано. Прелоады? Уже все загружено. Выгрузки ненужно чего? Не нужного кому?
Здравствуйте, Mike Chaliy, Вы писали:
MC>Ндя. Мы так мы всетаки горим прос домашние странички?
Кто про что говорит, мы уже давно разобрались...
MC>Борьба с ветряными мельбницами, это попытка использование системы не так как она задизайнерена
Вы не поняли. Основной вопрос был — "какого хрена система так криво задизайнена?"
MC>При том что если ты поменяеш название страницы. ТО эту ошибку ты тоже не отловиш при компиляции.
Наличие ошибок не отлавливаемых при компиляции — это не повод увеличивать количество таких ошибок. Не смущает то что c# вообще-то язык типизированный?
MC> Вобщемто я не вижу в этом проблемы.
Напрасно, тогда действительно разговаривать не о чем.
На самом деле, это очень большая проблема. При разработке на нетипизированных языках эта проблема отчасти сглаживается с помощю unit-тестов, но в данном случае, даже cs код относится к UI, а UI unit-тестами не покроешь. Так что количество проблем вызываемых этим косяком растет раза в два быстрее чем сам проект, и избежать этого практически невозможно. Вот просидите на рефакторинге проекта пол-дня, вместо пятнадцати минут, изображая из себя специалиста по QA, из-за этой вот "не проблемы", может понимание и придет.
MC> Поэтому и чепуха.
Я же предупреждал, не надо так откровенно демонстрировать свои заблуждения.
MC> И че так прямо автоматом и делаете замены?
А для чего по Вашему Refactoring инструменты нужны и за счет чего они работают? Во многом именно из-за возможности такой замены и того, что даже если при этом вылезет ошибка, то она будет отловлена компилятором, c# и пользуется такой популярностью.
MC> А потом обьясняете всей команде и ПМ зачем вы расчекаутили полторы тысячи файлов?
Слово Refactoring знакомо?
Здравствуйте, Mike Chaliy, Вы писали:
MC>Здравствуйте, Sacode, Вы писали:
S>>Судя по декомпиляции ODS и BuildManager'а все сборки подгружаются по первому требованию любого. Это первое требование приходит гораздо раньше, чем начинает работать ODS. S>>Так что разницы никакой, за исключением того, что BuildManager может найти больше одного класса с указанным в ODS именем, и тогда: S>>
S>>throw new HttpException(SR.GetString("Ambiguous_type", new object[] { typeName, Util.GetAssemblySafePathFromType(type1), Util.GetAssemblySafePathFromType(type2) }));
S>>
S>>
MC>Ткните пальчиком где они загружаються. Все сборки тока компиляться по первому требованию. Gollum уже это говрил. Для любителей полазить внутри надо искать метод EnsureTopLevelFilesCompiled. А подгружаються они по правилам дотНета.
После EnsureTopLevelFilesCompiled() в BuildManager.TheBuildManager.TopLevelReferencedAssemblies — загруженные сборки.
Если бы они были загружены с помощью ReflectionOnlyLoad() попытка создать экземпляр класса, или вызвать статический метод привели бы к исключению. Следовательно они загружаются в контекст выполнения, при этом, кстати, подгружая все зависимости.
Здравствуйте, Sacode, Вы писали:
S>Здравствуйте, Mike Chaliy, Вы писали:
MC>>Здравствуйте, Sacode, Вы писали:
S>>>Судя по декомпиляции ODS и BuildManager'а все сборки подгружаются по первому требованию любого. Это первое требование приходит гораздо раньше, чем начинает работать ODS.
Был неправ сорри.
Хотя есть еще. Тоесть если подгружаються другие собрки, то они будут подгружаться позжее.
Type type1 = null;
if (Util.TypeNameContainsAssembly(typeName))
{
type1 = Type.GetType(typeName, throwOnError, ignoreCase);
if (type1 != null)
{
return type1;
}
}
Ну и плюс зависимоти не подгружаються. Теститься просто. Создеться сборка. Референситься в сайт. Потом заускаеться без создания обьекта. Смотриться на отсутвие записей. Потом запускаеться с созданием обьекта. Смотриться на присутвие записей. Собтвенно я реально был уверен что точно также постоупают и с классам в Апп_Коде.
//Class1 cc = new Class1();
//cc.Aa = "asd";
Assembly[] assemblies = AppDomain.CurrentDomain.GetAssemblies();
foreach (Assembly assembly in assemblies)
{
Type t = assembly.GetType("TryDataSourceProject.Class1");
if (t != null)
{
this.Response.Write(t);
this.Response.Write("\r\n");
this.Response.Write(assembly);
}
}
Здравствуйте, Sacode, Вы писали:
S>Здравствуйте, Mike Chaliy, Вы писали:
S>Мы используем SOA и Agile (MSF for Agile). Контракты веб-сервисов меняются часто пока пишутся, потом создаются новые версии. Утвержденной спеки во время разработки у нас нет, она появляется после альфа, или даже бета версии (т.е. когда появляются зависимости других проектов от нее). Спецификации, контракты, интерфейсы, схемы БД — это обыкновенный продукт разработки и как и другие продукты разработки изменяется во время разработки. Это наш случай. Есть случаи, когда спецификация оговаривается заранее, но слепо ей следовать до конца, при наличии явных проблем — глупо. Поэтому любые спецификации меняются, меняются названия, и как следствие — проблемы.
Ну, далеко не у всех ХР. Хотя если микрософт за это взялся, то думаю скоро будет у всех ).
S>Кеши чего? Прекомпилы? Уже все скомпилировано. Прелоады? Уже все загружено. Выгрузки ненужно чего? Не нужного кому?
Вашему серверу. Все что угодно. Я назвал только то что лежит на поверхности. Эта фактори, это то место которое будет в случае необходимости оптимизировать микрософт. Про подгрузку прочтите мой ответ. Хотя возможно что опять гдето не доглядел.
Это проверяется, указана ли сборка в названии класса, если указана, то ничего искать не надо, использовать механизм BuildManager'а не надо, а просто тупо загрузить сборку (если уже не загружена) и взять из нее тип (собственно это и делает Type.GetType(...)).
Пример названия класса с указанием сборки:
Здесь Microsoft.Web.Services3 — как раз сборка.
По-умолчанию дизайнер засовывает название класса в ODS без указания сборки, так что для ODS этот блок не работает.
MC>Ну и плюс зависимоти не подгружаються. Теститься просто. Создеться сборка. Референситься в сайт. Потом заускаеться без создания обьекта. Смотриться на отсутвие записей. Потом запускаеться с созданием обьекта. Смотриться на присутвие записей. Собтвенно я реально был уверен что точно также постоупают и с классам в Апп_Коде.
MC>
MC>//Class1 cc = new Class1();
MC>//cc.Aa = "asd";
MC>Assembly[] assemblies = AppDomain.CurrentDomain.GetAssemblies();
MC>foreach (Assembly assembly in assemblies)
MC>{
MC> Type t = assembly.GetType("TryDataSourceProject.Class1");
MC> if (t != null)
MC> {
MC> this.Response.Write(t);
MC> this.Response.Write("\r\n");
MC> this.Response.Write(assembly);
MC> }
MC>}
MC>
MC>Поправляйте если что не так.
Попробуй следующий код:
Assembly[] assemblies = AppDomain.CurrentDomain.GetAssemblies();
foreach (Assembly assembly in assemblies)
{
Type t = assembly.GetType("TryDataSourceProject.Class1");
if (t != null)
{
this.Response.Write(t);
this.Response.Write("\r\n");
this.Response.Write(assembly);
}
}
Class1 cc = new Class1();
cc.Aa = "asd";
Assembly[] assemblies = AppDomain.CurrentDomain.GetAssemblies();
foreach (Assembly assembly in assemblies)
{
Type t = assembly.GetType("TryDataSourceProject.Class1");
if (t != null)
{
this.Response.Write(t);
this.Response.Write("\r\n");
this.Response.Write(assembly);
}
}
И сравни что выводит первый цикл, и что выводит второй. Следуя твоему предположению в первом списке должна отсутствовать сборка с Class1.
Что-то мне подсказывает, что она там будет.
Здравствуйте, Sacode, Вы писали:
S>Здравствуйте, Mike Chaliy, Вы писали:
S>Это проверяется, указана ли сборка в названии класса, если указана, то ничего искать не надо, использовать механизм BuildManager'а не надо, а просто тупо загрузить сборку (если уже не загружена) и взять из нее тип (собственно это и делает Type.GetType(...)).
Я в курсе что ОДС использует по умолчанию. Это уже не относиться к ОДС. Точнее используеться если дата обьект находиться в другой сборке.
Я имею ввиду што в этом случае сборка не будет предподгружена. Она будет подгружена только когда понядобиться. Это стандарная фитча. Ексепшен о том что сборка ненайдена выдаеться не при загрузке главной сборки. А только когда она понядобиться. Тоесть когда начнет выполняться класс в котором она используеться.
S>Попробуй следующий код: S>И сравни что выводит первый цикл, и что выводит второй. Следуя твоему предположению в первом списке должна отсутствовать сборка с Class1. S>Что-то мне подсказывает, что она там будет.
Обе естевенно выводят. На всякий пожарный я деже попробовал. Тока я не понимаю с каих это еще моих слов такое выходит. Я же уже говорил что если сборка прореференсена это не обозначает что она будет подгружена.
Здравствуйте, Mike Chaliy, Вы писали:
MC>Здравствуйте, Sacode, Вы писали:
S>>Это проверяется, указана ли сборка в названии класса, если указана, то ничего искать не надо, использовать механизм BuildManager'а не надо, а просто тупо загрузить сборку (если уже не загружена) и взять из нее тип (собственно это и делает Type.GetType(...)). MC>Я в курсе что ОДС использует по умолчанию. Это уже не относиться к ОДС. Точнее используеться если дата обьект находиться в другой сборке.
Это используется, когда в ODS задано название класса с указанием сборки. В этом случае референс на эту сборку делать не обязательно. Вот если не делать референс и в ODS указать название со сборкой, то загрузка сборки будет действительно только при первом обращении к ODS. Во всех остальных случаях сборка загружается гораздо раньше.
MC>Обе естевенно выводят. На всякий пожарный я деже попробовал. Тока я не понимаю с каих это еще моих слов такое выходит. Я же уже говорил что если сборка прореференсена это не обозначает что она будет подгружена.
Здравствуйте, Sacode, Вы писали:
S>А в какой момент она тогда грузится?
Грубо говоря, когда понадобится. Я не вижу здесь проблем с производительностью, тем более что то,что оно будет доставать реально нужно для работы страницы.
Здравствуйте, Mike Chaliy, Вы писали:
G>>Ветка показывает что вас не понимает как минимум два человека.
MC>В этом нет ничего сташного. Што вам што мне всерано. Жаль что никто не получил новой инфы.
Было бы все равно, я бы ничего не писал здесь.
MC>Ндя. Вы с HyperLink никогда не сталкивались? Ну или просто тегом a. Че вы там на типизируете?
В HyperLink вроде все типизировано. Тэги html напрямую стараюсь не использовать, предпочитаю серверные контролы.
Мы уже победили, просто это еще не так заметно...
).