1) Вопрос:
Почему ObjectDataSource тудно создавать в кодебехаинде.
Ответ:
Потому что он предназначен только для дизайн тайма. Реально это обертка над обьектом бизнес слоя. Так што если вам надо получить данные из биснес слоя в кодебехаинде надо так и зделать, а не городить эту обертку.
2) Вопрос:
Почему ObjectDataSource не типизирован.
Ответ:
Он использует BuildManager который принимает строку. Соответвенно нет необходимости делать его типизированым. Более того на момент компиляции страницы бизнс слоя может еще не существовать. Поєтому и используеться BuildManager.
Ok, продолжим здесь.
MC>Потому что он предназначен только для дизайн тайма.
Ответ неверный. То что он для дизайн-тайма не объясняет отсутствия нормального механизма без дизайн-тайма.
MC>Так што если вам надо получить данные из биснес слоя в кодебехаинде надо так и зделать, а не городить эту обертку.
Как мне прибайндить в бизнес-слое набор бизнес-объектов к гриду, обеспечив при этом нормальный пэйджинг?
Под нормальным пейджингом я понимаю, что для того чтобы реализовать пейджинг, грид не будет выгребать весь набор данных при каждом запросе, а достанет из бизнес-объекта только нужную страницу, но при этом он сам нарисует все нужные стрелочки, номера страничек и корректно обработает соответствующие события.
MC>Он использует BuildManager который принимает строку.
Его проблемы, почему нет механизма, который не использует?
MC>Соответвенно нет необходимости делать его типизированым.
Необходимость есть, нет возможности.
MC> Поєтому и используеться BuildManager.
Если бы ODS использовал интерфейсы для тех же вещей, то небыло бы необходимости его использования.
Почему нельзя было сделать нормальный баиндинг, а уже вокруг придумать какие угодно приседания для помещения этого дела в aspx.
Не совсем понимаю предмет спора. У Вас всеравно есть бизнес объект, которому ничего не мешает возращать типизированную коллекцию. Если UI вашего приложения выполняет ряд стандартных процедур(добавление, редактирование и удаление) и при этом не требуется никаких специфических действий(что характерно для небольших типовых приложений уровня веб-магазина) то бесспорно удобно использовать ODS. Однако если к вашему приложению требования гораздо выше, нужен custom paging и т.д. что мешает вам биндить на коллекцию без использования ODS?
Здравствуйте, ApplicationException, Вы писали:
AE>Не совсем понимаю предмет спора. У Вас всеравно есть бизнес объект, которому ничего не мешает возращать типизированную коллекцию. Если UI вашего приложения выполняет ряд стандартных процедур(добавление, редактирование и удаление) и при этом не требуется никаких специфических действий(что характерно для небольших типовых приложений уровня веб-магазина) то бесспорно удобно использовать ODS. Однако если к вашему приложению требования гораздо выше, нужен custom paging и т.д. что мешает вам биндить на коллекцию без использования ODS?
Собственно проблема в том что IB незнает как это сделать. Более того похоже он мне неверит что грид может показывать все что реализует IEnumerable и еже с ним.
В кратце я ему уже расказал как это делаеться, но вобщемто видемо неполучилось ). Ну а на большее у меня нервов нехватает. Вот хочеться человеку заюзать ODS и все тут. То что от него никакой функцмональности его это просто тупо не волнует (это ессно для кодебехаинда).
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Mike Chaliy, Вы писали:
IB>Ok, продолжим здесь.
MC>>Потому что он предназначен только для дизайн тайма. IB>Ответ неверный. То что он для дизайн-тайма не объясняет отсутствия нормального механизма без дизайн-тайма.
Вы так и несказали какой такой механизм вам нужен не в дизайн тайме.
MC>>Так што если вам надо получить данные из биснес слоя в кодебехаинде надо так и зделать, а не городить эту обертку. IB>Как мне прибайндить в бизнес-слое набор бизнес-объектов к гриду, обеспечив при этом нормальный пэйджинг? IB>Под нормальным пейджингом я понимаю, что для того чтобы реализовать пейджинг, грид не будет выгребать весь набор данных при каждом запросе, а достанет из бизнес-объекта только нужную страницу, но при этом он сам нарисует все нужные стрелочки, номера страничек и корректно обработает соответствующие события.
Плз. Реализуйте это любыми доступными вам средсвами. А я это же реализую в кодебехаинде.
MC>>Он использует BuildManager который принимает строку. IB>Его проблемы, почему нет механизма, который не использует?
Не использует что? Вы опять про то что надо передавать тип? Господи. Ну, это просто невежество. Разберитесь с механизмами компиляции страниц. Пропаблишите сайт. Поглядите кто куда референсица.
MC>>Соответвенно нет необходимости делать его типизированым. IB>Необходимость есть, нет возможности.
Пусты слова. В чем заключаеться необходимость? Если вообще ненужен ОДС. Зачем тогда такая функциональность?
MC>> Поєтому и используеться BuildManager. IB>Если бы ODS использовал интерфейсы для тех же вещей, то небыло бы необходимости его использования.
Таже песня про невежество.
IB>Почему нельзя было сделать нормальный баиндинг, а уже вокруг придумать какие угодно приседания для помещения этого дела в aspx.
Потому что он (нормальный биндинг) есть, был и будет. А вот собственно ОДС это и есть "что угодно для помешения хтого дела в аспх".
Здравствуйте, Mike Chaliy, Вы писали:
MC>Вы так и несказали какой такой механизм вам нужен не в дизайн тайме.
Например, точно такой же как ODS, но на интерфейсах. Допустим, для пейджинга существовал бы интерфейс IPagableBind с методом SelectPage(PageNum, RowsPerPage) и свойством TotalCount. И если я хочу реализовать кастомный пейджинг по своей коллекции, то мне достаточно было бы реализовать этот интерфейс и подпихнуть нужный объект контролу.
MC>Плз. Реализуйте это любыми доступными вам средсвами.
Так есть же готовый механизм, он меня полностью устраивает, но вот только работает он лишь при условии, что я использую ODS.
Специально, для самых вежественных:
Of the data source controls that are included in the .NET Framework, only the ObjectDataSource control supports returning a single page of data.
(c) MSDN
MC>Не использует что?
Не использует BuildManager.
MC>Ну, это просто невежество.
Это просто кто-то понять не может о чем речь... Не надо хамить, просто переспросите — я поясню, мне не сложно.
MC> Разберитесь с механизмами компиляции страниц. Пропаблишите сайт. Поглядите кто куда референсица.
То есть, Вы утверждаете, что для полноценного байндинга необходимо использовать именно такой подход с передачей типа в виде строковых констант?
Кто там про невежество говорил?
MC>Пусты слова.
Не надо так откровенно признаваться в своих заблуждениях... =)
MC>В чем заключаеться необходимость?
Необходимость заключается в том, что передача типа в виде строковой переменной — крайне кривая конструкция и вообще, механизму описания байндинга не место в aspx.
MC> Если вообще ненужен ОДС. Зачем тогда такая функциональность?
Затем что ODS обеспечивает двунаправленый баиндинг и поддержку кастомного пэйджинга.
Есть идеи как сделать это без ODS? Уже не в первый раз спрашиваю.
У меня складывается четкое впечатление, что Вы не очень хорошо себе представляете возможности ODS.
MC>Потому что он (нормальный биндинг) есть, был и будет.
Ну так где он? Только не надо мне на DataSource кивать, он не двунаправленый и пейджинга кастомного не поддерживает.
MC>А вот собственно ОДС это и есть "что угодно для помешения хтого дела в аспх".
В том-то и дело, что он реализует ряд функций, который стандартный баиндинг делать не умеет.
Здравствуйте, ApplicationException, Вы писали:
AE>Однако если к вашему приложению требования гораздо выше, нужен custom paging и т.д. что мешает вам биндить на коллекцию без использования ODS?
Стандартный баиндинг, через DataSource, однонаправленый и кастом-пейджинга не поддерживает, приходится делать все это в ручную.
Здравствуйте, Mike Chaliy, Вы писали:
MC>Собственно проблема в том что IB незнает как это сделать.
Ну так покажите, уже в который раз прошу. Только с условиями задачи ознакомьтесь внимательно.
Баиндинг должен быть двунаправленый и поддерживать кастом-пейджинг, жду.
MC> Более того похоже он мне неверит что грид может показывать все что реализует IEnumerable и еже с ним.
Сдается мне, что кто-то не верит, что существуют задачки по сложнее чем просто отобразить список.
MC>В кратце я ему уже расказал как это делаеться, но вобщемто видемо неполучилось
В кратце, я уже десять раз намекнул, что рассказ был не про то.
MC> Ну а на большее у меня нервов нехватает.
Я понимаю, тяжело так промахиваться, но на мне-то срываться не стоит... =)
MC> Вот хочеться человеку заюзать ODS и все тут.
Мне хочется не ODS, а его функциональность.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Mike Chaliy, Вы писали:
MC>>Плз. Реализуйте это любыми доступными вам средсвами. IB>Так есть же готовый механизм, он меня полностью устраивает, но вот только работает он лишь при условии, что я использую ODS. IB>Специально, для самых вежественных: IB>
IB>Of the data source controls that are included in the .NET Framework, only the ObjectDataSource control supports returning a single page of data.
IB>(c) MSDN
Так вот вы его и реализуйте. Просто набрасайте примерчик. Ненадо ничего военнго просто чтобы странички перключались. А я єтот примерчик в течении 10-15 минут перенсу на "нормальный" датабиндинг. Иначе у нас ниче не выйдет. Вы не хотите верить и не слышыте доводов. Будм доказывать практическими лабами .
Я собственно согласен с Иваном. Как раз на прошлой неделе боролся с этим чудом. В простеньких примерчиках все красиво,
в принципе для биндинга всяких списков к комбобоксам самое оно. Еще если кеширование еще включить вообще замечательно (кеширование тоже кстати реализовано как то странно со своими особенностями которые пришлось изучать через гугл). Но вот когда началась реальность в виде простой задачи GridView + пейджинг + сортировка по всем колонкам тут пришлось поработать. По окончании возникли следующие вопросы:
— те же строки типов и методов в aspx, какого в 21 век я должен искать использование метода поиском т.к. FindUsages отдыхает в случае ODS.
— какой ... придумал что нужен отдельный метод для получения количества записей при пейджинге?
— нафига был сделал кривой дизайнер настройки если все равно код контрола в aspx приходится чистить руками т.к. он туда начинает пихать все что нужно и не нужно. Те же параметры которые можно не указывать при совпадении имен параметров (мдя...) он пихает в дизайнер?
Все заработало в итоге но... "Нихрена себе упрощение работы" сказал я глядя на результат
Засев после этого безобразия за гугл узнал много интересного про ODS. Оказывается я не на все грабли наступил, их у него еще вагон и тележка. Еще оказалось что внутри все через reflection и еще многих людей мучают те же вопросы что и меня
Как результат нашел хороший туториал по ODS с описанием кучи граблей. Автор в итоге написал свой контрол (правда сделал он его коммерческим объясняя тем что много времени на него потратил) где постарался обойти большинство проблем. Если интересно здесь можно посмотреть возможности контрола с опиcанием проблем ODS, а здесь сравнение возможностей ODS с его контролом. В связи с отсутсвием времени его контрол я так и не посмотрел. Не думаю что это идеал и в нем нету недостатков. Но ведь можно же если захотеть
Здравствуйте, Mike Chaliy, Вы писали:
MC>Так вот вы его и реализуйте.
Что реализовыать-то, все уже есть.
MC> Просто набрасайте примерчик.
Реализуем объеткт:
public class PageRequestDataSource
{
// выборка конкретной страницы
//public DataTable SelectPage(int maximumRows, int startRowIndex)
{ ... }
// Общее количество записей в коллекции
//public int RowCount()
{ ... }
}
Все. Редактирование, добавление, удаление делается так же...
Да, на заметку:
To bind to a data source that implements the System.Collections.IEnumerable interface, programmatically set the DataSource property of the GridView control to the data source and then call the DataBind method. When using this method, the GridView control does not provide built-in sorting, updating, deleting, and paging functionality.
(c) MSDN
Вот это-то мне и надо, мнея вполне устраивает эта built-in functionality, меня не устраивает только то, что она требует использования ODS.
MC>Вы не хотите верить и не слышыте доводов.
Каких доводов?
MC>Будм доказывать практическими лабами .
Вэлкам.
1. Mike, Вы часом не из Валидио будете ? (Если да, то привет коллеге — рад видеть на RSDN'e) 2. С IB лучше не спорьте — чертовски умный малый, заслуживает уважения. Конечно, это не отрицает того факта, что Иван не может ошибаться, но интуиция подсказывает, что опыту у него побольше чем у нас вместе взятых (Ладно, я не в счет: у меня вообще опыту нет почти ). Другими словами я склоняюсь к тому, что Иван прав... 3. Сорри, что придираюсь, но в Русском есть довольно простое правило, типа "не" с глаголами раздельно пишется. Еще раз сорри — глаз режет.
[/offtopic]
Все выше сказанное очень-очень ИМХО.
ЗЫЖ Программирование очень сложное занятие. Профессиональные программисты всегда сомневаются, т.к. понимают, что не могут знать всего. Пожалуй, осознание своего несовершенства — это один из атрибутов профи, навреное. Хотя, я могу и ошибаться — я не идеален .
Здравствуйте, IB, Вы писали:
MC>>Вы так и несказали какой такой механизм вам нужен не в дизайн тайме. IB>Например, точно такой же как ODS, но на интерфейсах. Допустим, для пейджинга существовал бы интерфейс IPagableBind с методом SelectPage(PageNum, RowsPerPage) и свойством TotalCount. И если я хочу реализовать кастомный пейджинг по своей коллекции, то мне достаточно было бы реализовать этот интерфейс и подпихнуть нужный объект контролу.
Это можно сделать самому написав простенького наследника от DataSourceControl. Почему этого не сделали в MS? Думаю не очень они хотят делать все универсально — иначе партнерам ничего не достанется. К тому же здесь возникает небольшая сложность с тем, что методов извлечения данных, в отличии от методов изменения, обычно больше одного. Можно, конечно, сделать несколько классов для разных методов, но как-то это не красиво. Хотя может и поробую на днях, самого достали косяки ODS.
MC>> Разберитесь с механизмами компиляции страниц. Пропаблишите сайт. Поглядите кто куда референсица. IB>То есть, Вы утверждаете, что для полноценного байндинга необходимо использовать именно такой подход с передачей типа в виде строковых констант? IB>Кто там про невежество говорил?
Не вопрос не в том что лучше использовать для бандинга, а в том что будет работать как контрол на странице. На странице нет нормального способа присвоить свойству что-либо кроме строки. Вот если бы можно было написать:
Вот и приходится для поддержки дизайнера страниц использовать строки, а не типы. Мне кажется об этом говорил MC.
MC>>В чем заключаеться необходимость? IB>Необходимость заключается в том, что передача типа в виде строковой переменной — крайне кривая конструкция и вообще, механизму описания байндинга не место в aspx.
Про первый пункт написал выше, а вот про второй можно и по-подробней. Я не спорю, я спрашиваю — где ему место?
MC>> Если вообще ненужен ОДС. Зачем тогда такая функциональность? IB>Затем что ODS обеспечивает двунаправленый баиндинг и поддержку кастомного пэйджинга. IB>Есть идеи как сделать это без ODS? Уже не в первый раз спрашиваю.
См. первый пункт.
MC>>А вот собственно ОДС это и есть "что угодно для помешения хтого дела в аспх". IB>В том-то и дело, что он реализует ряд функций, который стандартный баиндинг делать не умеет.
Есть такой пункт. При всех недостатках, ObjectDataSource — это наилучший вариант из фреймворка.
Здравствуйте, Sacode, Вы писали:
S>Это можно сделать самому написав простенького наследника от DataSourceControl.
Его же все равно придется помещать в aspx, да и не такой уж он и простенький получается.
S> Думаю не очень они хотят делать все универсально — иначе партнерам ничего не достанется.
Тут просто заводит в тупик нелогичность решения. Ведь ровно этот же функционал можно было бы реализовать в самостоятельном классе, а уже потом обернуть его в DataSourceControl.
S> К тому же здесь возникает небольшая сложность с тем, что методов извлечения данных, в отличии от методов изменения, обычно больше одного. Можно, конечно, сделать несколько классов для разных методов, но как-то это не красиво.
Достаточно задекларировать несколько интерфейсов, а реализовать их можно в одном классе.
S>Вот и приходится для поддержки дизайнера страниц использовать строки, а не типы. Мне кажется об этом говорил MC.
Это все понятно, я-то говорю о том, что если убрать этот код из контрола и реализовать его в нормальном классе, то и проблем с компиляцией бы не было.
S> Я не спорю, я спрашиваю — где ему место?
В контроллере, если пользоваться терминологией MVC.
S> При всех недостатках, ObjectDataSource — это наилучший вариант из фреймворка.
Об чем и речь.
Здравствуйте, Mike Chaliy, Вы писали:
MC>По мотивам:
MC>Что не так в ObjectDataSource...
MC>Ваше мнение?
MC>Собственно мое мнение:
MC>1) Вопрос: MC>Почему ObjectDataSource тудно создавать в кодебехаинде. MC>Ответ: MC>Потому что он предназначен только для дизайн тайма. Реально это обертка над обьектом бизнес слоя. Так што если вам надо получить данные из биснес слоя в кодебехаинде надо так и зделать, а не городить эту обертку.
MC>2) Вопрос: MC>Почему ObjectDataSource не типизирован. MC>Ответ: MC>Он использует BuildManager который принимает строку. Соответвенно нет необходимости делать его типизированым. Более того на момент компиляции страницы бизнс слоя может еще не существовать. Поєтому и используеться BuildManager.
Если у кого есть конкретные мысли или наработки по поводу решения этих проблем — публикуйте. Хочется уже нормального ODS'а.
У меня требования такие:
1. Полная поддержка дизайнера. Т.е. чтобы можно было сделать страницу вообще без код-бихайнда. (Есть в имеющемся ODS)
2. Поддержка как автоматического (без написания какого-либо кода) механизма пейджинга/сортировки (пусть даже с использованием Reflection), так и обязательно — ручного, чтобы можно было передать выполнение пейджинга/сортировки в другие слои и/или ускорить.
3. Кеширование с поддержкой внешней реализации (например Microsoft.Practices.EnterpriseLibrary.Caching).
4. Наверняка что-то еще...
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Sacode, Вы писали:
S>>Это можно сделать самому написав простенького наследника от DataSourceControl. IB>Его же все равно придется помещать в aspx, да и не такой уж он и простенький получается.
Да, с ASPX лажа. Есть более сложный вариант — интерфейсы IDataSource, IListSource. Тогда можно и не в ASPX.
S>> Думаю не очень они хотят делать все универсально — иначе партнерам ничего не достанется. IB>Тут просто заводит в тупик нелогичность решения. Ведь ровно этот же функционал можно было бы реализовать в самостоятельном классе, а уже потом обернуть его в DataSourceControl.
Согласен.
S>> К тому же здесь возникает небольшая сложность с тем, что методов извлечения данных, в отличии от методов изменения, обычно больше одного. Можно, конечно, сделать несколько классов для разных методов, но как-то это не красиво. IB>Достаточно задекларировать несколько интерфейсов, а реализовать их можно в одном классе.
Есть, например, интерфейсы ISelect, IUpdate, IDelete, IPagedSelect : ISelect, ISortedSelect : ISelect
Вот с помощью этих интерфейсов надо описать следующий класс:
public class DataManager
{
public List<Entity> GetAllEntities();
public List<Entity> GetAllEntities(int maximumRows, int startRowIndex, string sortExpression);
public int GetAllEntitiesCount();
public List<Entity> GetEntitiesByName(string name);
public List<Entity> GetEntitiesByName(string name, int maximumRows, int startRowIndex, string sortExpression);
public int GetEntitiesByNameCount(string name);
public Entity GetEntityById(int entityId);
public void DeleteEntityById(int entityId);
public void InsertEntity(Entity entity);
public void UpdateEntity(Entity entity);
}
Или я не правильно понял интерфейсы?
S>>Вот и приходится для поддержки дизайнера страниц использовать строки, а не типы. Мне кажется об этом говорил MC. IB>Это все понятно, я-то говорю о том, что если убрать этот код из контрола и реализовать его в нормальном классе, то и проблем с компиляцией бы не было.
Да, но это ни в коем случае не должно отменять удобство и простоту работы с дизайнером. Я вообще настаиваю на том, чтобы код-бихайнд был максимально минимален
Это когда команда разношерстная по квалификации. А MS для таких и пишет свои контролы. Лень им, наверное было сделать все по-уму.
S>> Я не спорю, я спрашиваю — где ему место? IB>В контроллере, если пользоваться терминологией MVC.
Преимущества паттернов MVC/MVP что-то для меня сомнительны для большенства веб-проектов. Не наглядно это, сложнее.
На мой взгляд если нужно иметь несколько представлений для одного контроллера (по терминологии MVC), то другого варианта и нет. А если представление одно, то смысла городить MVC не вижу.
ИМХО, конечно, можешь переубедить.
S>> При всех недостатках, ObjectDataSource — это наилучший вариант из фреймворка. IB>Об чем и речь.
Может решим эту проблему? Мне нужно решение, но тратить на него много времени нет возможности.
Как насчет реализации интерфейсов из первого пункта?
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Mike Chaliy, Вы писали:
[skipped]
Соррики я уже давно бахнул тот топик. Его глупо было писать. Видемо модеры недоглядели.
Теперь по поводу реализации с нормальным датабиндингом. Я зря про нее сказал.
— Вопервых ГридВию неразрешает упровлять пейджером. Поэтому придеться реализовывать свой темплейт для пейджера, а это долго.
— Все остальное реализовываеться при помощи евентов. Опять же долго.
Я понмаю что реализация будет больше при возможной с "нормальным" ОДС но при этом вы же любитим трудности? Зачем на те дизайнеры?
Ладно. Это я уже срываюсь. Собтвенно я признал что в ВАШЕМ случае вам лучше не использовать стандартный ОДС ). А я как использовал его с дизайнра так и буду ). И я признаю что ПРОИГРАЛ.
Все что дальше не относиться к предыдущей беседе. Так как уже признал что НЕПРАВ.
Теперь по поводу типизированности. Маленький ньюансик. Ну есть IPagableBind. Я ж так понял его должен реализовывать адаптер бизнес обектов. Гы. А если я захочу поменять сигнатуру метода? Или заставить всех писать бизнес обьекты с четырмя методами? Или позаставлять всех делать фактори?
Хы. Я заню как оно должно быть типизированным. Надо ПропертиИнфо туда биндить, ну или ПропертиДескриптор. Кстити я ж так понял вы будет реализовывать свой дата соурсе. Очень будет интесно скока десятков ТипКонвертеров вы напедплите чтобы оно все в маркапе потдерживалось. Собственно об этом уже сказал Sacode.
Предложите свою реализацию.
Здравствуйте, Sacode, Вы писали:
S>Здравствуйте, Mike Chaliy, Вы писали:
S>Если у кого есть конкретные мысли или наработки по поводу решения этих проблем — публикуйте. Хочется уже нормального ODS'а. S>У меня требования такие: S>1. Полная поддержка дизайнера. Т.е. чтобы можно было сделать страницу вообще без код-бихайнда. (Есть в имеющемся ODS) S>2. Поддержка как автоматического (без написания какого-либо кода) механизма пейджинга/сортировки (пусть даже с использованием Reflection), так и обязательно — ручного, чтобы можно было передать выполнение пейджинга/сортировки в другие слои и/или ускорить. S>3. Кеширование с поддержкой внешней реализации (например Microsoft.Practices.EnterpriseLibrary.Caching). S>4. Наверняка что-то еще...
1. Есть. Вы точно имелли ввиду не кодебехаинд?
2. Только вторая часть. Первая если надо реализовываеться ГридВью.
3. Переносите кеш в адаптер бизнес обьектов.
Здравствуйте, Sacode, Вы писали:
S> Есть более сложный вариант — интерфейсы IDataSource, IListSource. Тогда можно и не в ASPX.
Если я правильно понял, то IDataSource все равно должен быть реализован контролом, иначе ты его в контрол не подпихнешь.
S>Или я не правильно понял интерфейсы?
Да, примерно так...
S>Да, но это ни в коем случае не должно отменять удобство и простоту работы с дизайнером. Я вообще настаиваю на том, чтобы код-бихайнд был максимально минимален
Ну, вообще-то дизайнеру должно быть пофигу гуда код генерить.
S>Это когда команда разношерстная по квалификации.
А если разношерстна, то при запихивании всего что можно в aspx такая каша получится....
S>Преимущества паттернов MVC/MVP что-то для меня сомнительны для большенства веб-проектов. Не наглядно это, сложнее.
Классический MVC действительно немного запутан, а вот MVP как раз прозрачнее и четче обычной каши из aspx и сопутствующего ему .cs.
S>На мой взгляд если нужно иметь несколько представлений для одного контроллера (по терминологии MVC), то другого варианта и нет. А если представление одно, то смысла городить MVC не вижу. S>ИМХО, конечно, можешь переубедить.
Ну, вот аргументы за MVP даже в мелких проектах:
1. Тестирование. Если применяется TDD, то MVP позволяет вынести максимальнео количество кода из не тестируемой части и покрыть его тестами.
2. Обычно на код-бехаинд класс возлагаются функции обработчика событий, менеджера бизнес-процессов, медиатора между презентационной логикой и бизнес-слоем, а так же медиатора между бизнес-слоем и DAL. Такое, понятное дело, до добра не доводит и получается довольно равномерная субстанция в которой чертовски сложно разобраться. Использование MVP позволяет оставить в коде-бихайнде только презентационную логику.
3. Использование коде-бихаинд "в лоб", усложняет повторное использование логики на разных страницах. Она частенько бывает похожа и приходится придумывать хелперы и прочие приседания, чтобы не дублировать код. MVP эту проблема так же решает.
4. Если MVP реализован по схеме один контрол-один вью, то там переиспользования контрола с разными вьюшками — вагон, на некоторых типах проектов такой подход довольно удобен.
5. (мое любимое) Ты никогда не можешь быть увереным заранее, что в проекте не потребуется несколько вью.
S>Может решим эту проблему? Мне нужно решение, но тратить на него много времени нет возможности.
А мне уже и не нужно, пока... На текущем проекте я это дело замазал парой классов-оберток, больше там вряд ли потребуется, а дальше видно будет.
S>Как насчет реализации интерфейсов из первого пункта?
Могу набросать пару идей...
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Sacode, Вы писали:
S>> Есть более сложный вариант — интерфейсы IDataSource, IListSource. Тогда можно и не в ASPX. IB>Если я правильно понял, то IDataSource все равно должен быть реализован контролом, иначе ты его в контрол не подпихнешь.
S>>Или я не правильно понял интерфейсы? IB>Да, примерно так...
Я так понимаю, он просил раставить эти интрфейсы. В конце концов если не он это просит. То пожалуйста раставьте эти интерфейсы.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Sacode, Вы писали:
S>> Есть более сложный вариант — интерфейсы IDataSource, IListSource. Тогда можно и не в ASPX. IB>Если я правильно понял, то IDataSource все равно должен быть реализован контролом, иначе ты его в контрол не подпихнешь.
Вроде нет. Сам же прежлагал сделать реализацию интерфейсов отдельно, а потом обернуть все это в контрол, чтобы можно было пользоваться дизайнером.
На первый взгляд идея разумная и реализуемая.
S>>Или я не правильно понял интерфейсы? IB>Да, примерно так...
Не. Вопрос как отобразить класс работы с данными на эти интерфейсы. Вот тут и начинаются сложности...
Методов извлечения данных несколько GetAllEntities, GetEntitiesByName и пр., а в интерфейсе ISelect будет однин метод Select.
Вот и вопрос какими при этом должны быть интерфейсы?
S>>Это когда команда разношерстная по квалификации. IB>А если разношерстна, то при запихивании всего что можно в aspx такая каша получится....
Не, не всего. У нас есть отдельный слой — PresentationLogic, в нем сортировка, пейджинг и все приспособлено для ODS, а вот на странице и в код-бихайнде этого быть не должно.
Похже чем-то на MVC/MVP, только без интерфейсов и PresentationLogic ничего не знает о представлении, даже интерфейса, только страница ASPX знает и о модели и о PresentationLogic.
S>>На мой взгляд если нужно иметь несколько представлений для одного контроллера (по терминологии MVC), то другого варианта и нет. А если представление одно, то смысла городить MVC не вижу. S>>ИМХО, конечно, можешь переубедить. IB>Ну, вот аргументы за MVP даже в мелких проектах: IB>1. Тестирование. Если применяется TDD, то MVP позволяет вынести максимальнео количество кода из не тестируемой части и покрыть его тестами. IB>2. Обычно на код-бехаинд класс возлагаются функции обработчика событий, менеджера бизнес-процессов, медиатора между презентационной логикой и бизнес-слоем, а так же медиатора между бизнес-слоем и DAL. Такое, понятное дело, до добра не доводит и получается довольно равномерная субстанция в которой чертовски сложно разобраться. Использование MVP позволяет оставить в коде-бихайнде только презентационную логику. IB>3. Использование коде-бихаинд "в лоб", усложняет повторное использование логики на разных страницах. Она частенько бывает похожа и приходится придумывать хелперы и прочие приседания, чтобы не дублировать код. MVP эту проблема так же решает. IB>4. Если MVP реализован по схеме один контрол-один вью, то там переиспользования контрола с разными вьюшками — вагон, на некоторых типах проектов такой подход довольно удобен. IB>5. (мое любимое) Ты никогда не можешь быть увереным заранее, что в проекте не потребуется несколько вью.
Почти уверен. У нас в одном проекте было несколько представлений. Но очень сильно отличались и логикой и составом отображаемых данных. MV* ниразу бы не помогли, а вот наш PresentationLogic много раз повторно использовался.
S>>Может решим эту проблему? Мне нужно решение, но тратить на него много времени нет возможности. IB>А мне уже и не нужно, пока... На текущем проекте я это дело замазал парой классов-оберток, больше там вряд ли потребуется, а дальше видно будет.
Может распишешь как сделал?
S>>Как насчет реализации интерфейсов из первого пункта? IB>Могу набросать пару идей...
Давай, у нас грядет небольшой рефакторинг этой части, как раз будет кстати.
Здравствуйте, Mike Chaliy, Вы писали:
MC>Все что дальше не относиться к предыдущей беседе. Так как уже признал что НЕПРАВ.
Ок, проехали...
MC> Я ж так понял его должен реализовывать адаптер бизнес обектов. Гы. А если я захочу поменять сигнатуру метода?
А зачем?
MC> Или заставить всех писать бизнес обьекты с четырмя методами? Или позаставлять всех делать фактори?
Тут уже от конкретной ситуации зависит. Смысл в том, что для пэйджинга надо подпихнуть реализацию соответствующего интерфейса, кто и как это будет делать — дело десятое. По сути это ровно то что делает ODS, но я не прикован к aspx и все типизировано.
MC> Кстити я ж так понял вы будет реализовывать свой дата соурсе.
Пока нет, это я просто плакался на майкрософтовский...
MC>Предложите свою реализацию.
Сгладить проблему "в лоб" можно так:
Описать соответствующие интерфейсы типа IPageable, ISortable, ICacheable, ect...
Реализовтаь эти интерфейсы в обертке или самом объекте.
Заставить общаться контрол с объектом через эти интерфейсы, например реализовав своего наследника IDataSource.
Здравствуйте, IB, Вы писали:
MC>>Предложите свою реализацию. IB>Сгладить проблему "в лоб" можно так: IB>Описать соответствующие интерфейсы типа IPageable, ISortable, ICacheable, ect... IB>Реализовтаь эти интерфейсы в обертке или самом объекте. IB>Заставить общаться контрол с объектом через эти интерфейсы, например реализовав своего наследника IDataSource.
Собственно это понятно. Я имею ввиду поставьте себя на место микрософтовцев. Ну они в курсе что кроме таких людей как вы есть такие люди как я, которые без дизанеров жить не могут. Плюс проблема которую описал Sacode (Это я про несколько слект методов в одном дата обьекте). Вобщемто предположим что вам надо добиться максимальной отдачи при минмальных затратах. На какой реализации вы бы остановились?
Здравствуйте, Sacode, Вы писали:
S>Вроде нет. Сам же прежлагал сделать реализацию интерфейсов отдельно, а потом обернуть все это в контрол, чтобы можно было пользоваться дизайнером.
Да, но я не о том. Я к тому, что если мне, например, дизайнером пользоваться не надо, то я все равно вынужден лезть в aspx код и описывать этот контрол там.
S>Не. Вопрос как отобразить класс работы с данными на эти интерфейсы. Вот тут и начинаются сложности... S>Методов извлечения данных несколько GetAllEntities, GetEntitiesByName и пр., а в интерфейсе ISelect будет однин метод Select. S>Вот и вопрос какими при этом должны быть интерфейсы?
Ааа... Приерно так:
В классе, который реализует байндинг пришуся методы, которые принимают описанные интерфейсы и этот класс смотрит какие интерфейсы в наличии и работает через них.
Строго говоря, описывать сортировку и фильтрацию острой необходимости нет, так как класс создаешь ты сам и при инициализации все необходимые параметры можешь передать в обертку в нужном тебе виде.
Каким именно способом тебе реализовать тот или иной интерфейс пользуясь возможностями DataManager, опять-таки определяешь в адаптере — ему все известно.
S>Похже чем-то на MVC/MVP, только без интерфейсов и PresentationLogic ничего не знает о представлении, даже интерфейса, только страница ASPX знает и о модели и о PresentationLogic.
Ага, значит PresentationLogic — это просто хелпер, который содержит большинство общего функционала, я писал о таком подходе...
Это тестируется хуже чем MVP и вью по прежнему перегружен знаниями о модели и разруливанием связей между слоями.
S>Может распишешь как сделал?
По разному. В одном случае просто обертка над ODS, для пейджинга, а во втором пара классов-хелперов для двунаправленного байндинга, без использования ODS, там все примитивненько, благо больше не требовалось.
S>Давай, у нас грядет небольшой рефакторинг этой части, как раз будет кстати.
См. выше.
Здравствуйте, Mike Chaliy, Вы писали:
MC> Плюс проблема которую описал Sacode (Это я про несколько слект методов в одном дата обьекте).
Какой select метод из объекта использовать — определяет адаптер — тот класс, который реализует интерфейс. Это ровно тоже самое, чтоприходится делать сейчас при использовании ODS.
MC>Вобщемто предположим что вам надо добиться максимальной отдачи при минмальных затратах. На какой реализации вы бы остановились?
Я бы реализовал все через интерфейсы, а поверх бы этого прикрутил ODS для дизайнеров. Дело в том, что они все равно используют некие соглашения по клиентскому коду (при использовании ODS мы должны указать тип и его методы). И проблем задекларировать эти соглашения в явном виде через интерфейсы нет. В этом случае был бы единый механизм и для тех кто хочет использовать дизайнер идля тех кому он не нужен, сейчас же тем, кому дизайнер не нужен, приходится реализовывать руками то, что уже реализовано в MS.
Здравствуйте, IB, Вы писали:
S>>Не. Вопрос как отобразить класс работы с данными на эти интерфейсы. Вот тут и начинаются сложности... S>>Методов извлечения данных несколько GetAllEntities, GetEntitiesByName и пр., а в интерфейсе ISelect будет однин метод Select. S>>Вот и вопрос какими при этом должны быть интерфейсы? IB>Ааа... Приерно так: IB>
IB>В классе, который реализует байндинг пришуся методы, которые принимают описанные интерфейсы и этот класс смотрит какие интерфейсы в наличии и работает через них.
Дык вопрос в том, что при таком подходе в классе может быть только один метод Select, а в изначальном классе их три. Получается, что нужно делать три класса, по одному на каждый метод выборки. Или делать класс, который бы описывал метод и его параметры со значениями (типа паттерна Command) и его уже передавать методу Select.
Вот тут порыться еще надо...
S>>Похже чем-то на MVC/MVP, только без интерфейсов и PresentationLogic ничего не знает о представлении, даже интерфейса, только страница ASPX знает и о модели и о PresentationLogic. IB>Ага, значит PresentationLogic — это просто хелпер, который содержит большинство общего функционала, я писал о таком подходе... IB>Это тестируется хуже чем MVP и вью по прежнему перегружен знаниями о модели и разруливанием связей между слоями.
Насчет модели — да. Но по-моему напрасно стараться этого избежать — колонки, байндинг и пр. все-равно будут. А насчет связей не совсем понял. Используются методы PresentationLayer и ни каких других слоев больше не упоминается.
Схема такая:
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Mike Chaliy, Вы писали:
MC>>Вобщемто предположим что вам надо добиться максимальной отдачи при минмальных затратах. На какой реализации вы бы остановились? IB>Я бы реализовал все через интерфейсы, а поверх бы этого прикрутил ODS для дизайнеров. Дело в том, что они все равно используют некие соглашения по клиентскому коду (при использовании ODS мы должны указать тип и его методы). И проблем задекларировать эти соглашения в явном виде через интерфейсы нет. В этом случае был бы единый механизм и для тех кто хочет использовать дизайнер идля тех кому он не нужен, сейчас же тем, кому дизайнер не нужен, приходится реализовывать руками то, что уже реализовано в MS.
Вернемся к нашим баранам, в часности к BuildManager. Как вы думаете зачем он нужен? Мое мнение что он для лейт бинднига. Тоесть если в нашей страничке ненужен код из App_Code она не будет подгружать эту либу. Теперь разберемся с нашими примерами. В случае с реализацией через интрфейс код из App_Code нужен всегда. Даже если какойто колбек(аджакс) нетребующий перебиндивания будеты вызван, то будет подгружаться и App_Code. В случае с реализацией через BuildManager этого не будет. Он вообшще будет компилиться только на момент когда он понадобиться (ессно если не использовать прекомпил). Может быть всетаки лучше отдать прерогативу создания этих обьектов инраструктуре асп.нета? Поправте если че не так.
Здравствуйте, Mike Chaliy, Вы писали:
MC>Ответ: MC>Он использует BuildManager который принимает строку. Соответвенно нет необходимости делать его типизированым. Более того на момент компиляции страницы бизнс слоя может еще не существовать. Поєтому и используеться BuildManager.
App_Code компилируется перед as*x, так что все существует. Споры по поводу ObjectDatasource imho вообще бессмысленны. Вы же не возмущаетесь, что в странице можно использовать SqlDataSource? Это для экспресс-написания маленьких приложений.
По всей Смоленщине нет кокаина — это временный кризис сырья
Здравствуйте, Gollum, Вы писали:
G>Здравствуйте, Mike Chaliy, Вы писали:
MC>>Ответ: MC>>Он использует BuildManager который принимает строку. Соответвенно нет необходимости делать его типизированым. Более того на момент компиляции страницы бизнс слоя может еще не существовать. Поєтому и используеться BuildManager.
G>App_Code компилируется перед as*x, так что все существует. Споры по поводу ObjectDatasource imho вообще бессмысленны. Вы же не возмущаетесь, что в странице можно использовать SqlDataSource? Это для экспресс-написания маленьких приложений.
А с чего вы взяли что она в домене? Что ее не придеться подгружать? Ткните ка меня носом. А то чета не могу найти инфы по этому поводу.
Здравствуйте, Sacode, Вы писали:
S>Дык вопрос в том, что при таком подходе в классе может быть только один метод Select, а в изначальном классе их три. Получается, что нужно делать три класса, по одному на каждый метод выборки.
Зачем? У тебя же не стоит задача обязательно воспользоваться всеми методами DataManager, твоя задача — реализовать необходимый набор интерфейсов корректного байнднинга, ну и что, что при этом не все возможности DataManager будут использованы?
S> А насчет связей не совсем понял. Используются методы PresentationLayer и ни каких других слоев больше не упоминается. S>Схема такая:
А к модели и с DAL-ом у тебя кто обращается?
MC> В случае с реализацией через интрфейс код из App_Code нужен всегда.
Да он и так всегда нужен, даже при текущей схеме. Как только дело доходит до ODS он вынужден поднимать мой класс-обертку из код-бихаинда.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Mike Chaliy, Вы писали:
MC>> В случае с реализацией через интрфейс код из App_Code нужен всегда. IB>Да он и так всегда нужен, даже при текущей схеме. Как только дело доходит до ODS он вынужден поднимать мой класс-обертку из код-бихаинда.
Я вообщето привел пример с аджаксом которому ненужны данные. Ну например генерация календаря. Это все на одной страничке. Есть грид юзающий ОДС и календарик ничего не юзающий. Грид использует колбеки для пейджинга, а календарик для того чтобы перерендериться например при изменении месяца. Это синтетический пример. Суть не в нем. Суть в вопросе (повторюсь): Может быть всетаки лучше отдать прерогативу создания обьектов инраструктуре асп.нета?
Здравствуйте, Mike Chaliy, Вы писали:
MC>Суть в вопросе (повторюсь): Может быть всетаки лучше отдать прерогативу создания обьектов инраструктуре асп.нета?
Да байта ради, наличие интерфейса тут ничего не изменит. В одном случае ODS ссылается на произвольный класс, в другом на класс реализующий определенный набор интерфейсов, с точки зрения компиляции разницы никакой.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Mike Chaliy, Вы писали:
MC>>Суть в вопросе (повторюсь): Может быть всетаки лучше отдать прерогативу создания обьектов инраструктуре асп.нета? IB>Да байта ради, наличие интерфейса тут ничего не изменит. В одном случае ODS ссылается на произвольный класс, в другом на класс реализующий определенный набор интерфейсов, с точки зрения компиляции разницы никакой.
Вы не ответели на мой вопрос. Я не говорю про часный случай когда странице в любом ее состоянии нужны данный. Существуют состояния когда ей данные ненужны (я уже обрисовывал синтетическую ситуацию с колбеками, могу даже пример привести, например каледнадрик генерящийся на сервреи отдающейся через колбеки).
И еще раз подчеркну что ОДС не ссылаеться никуда. Там храниться строка, по кторой обьект достаеться только в момент DataBind.
И еще. Уже речь не идет про компиляцию. Как правилно заметил Gollum App_Code компилиться всегда. Теперь уже речь идет о подгрузки Апп_Коде в домен. Опять же про ситуацию когда по какойто причине на момент колбека Апп_Коде в домен не подгружена.
Я просто к чему подвожу. К универсальности решения. Микрософт сдела фактори для создания обьектов. Я не вижу причины по которой не использовать собтвенно эту фактори? Как минимум это подерживаемое решение, и микрософт на него не забьет(теоретически). Более того как по мне так следующий асп.нет будет очень завязан на колбеках и тому подобному. Я уже гдето слышал про то што туда включат атлас. А это обозначает что значение этого механизма может в одночасье вырости ).
С другой стороны я не вижу ограничений и на прямое создание обьекта. Мои примеры достаточно синтетически. Да и к томуже затратами на подгрузку Апп_Кода можно пренебречь.
Здравствуйте, Mike Chaliy, Вы писали:
MC>Вы не ответели на мой вопрос.
Ответил.
MC>И еще раз подчеркну что ОДС не ссылаеться никуда. Там храниться строка, по кторой обьект достаеться только в момент DataBind.
Замечательно. Так в чем разница, указывается в этой строке произвольный тип или тип реализующий конкретный набор интерфейсов?
MC>Я просто к чему подвожу. К универсальности решения.
Решение с интерфейсами более универсально, оно не требует обязательного присутствия ODS в aspx.
MC> Микрософт сдела фактори для создания обьектов. Я не вижу причины по которой не использовать собтвенно эту фактори?
Я вижу — эта фабрика не типизирована и привязана к aspx.
Здравствуйте, IB, Вы писали:
S>>Дык вопрос в том, что при таком подходе в классе может быть только один метод Select, а в изначальном классе их три. Получается, что нужно делать три класса, по одному на каждый метод выборки. IB>Зачем? У тебя же не стоит задача обязательно воспользоваться всеми методами DataManager, твоя задача — реализовать необходимый набор интерфейсов корректного байнднинга, ну и что, что при этом не все возможности DataManager будут использованы?
Ну я и говорю, что получается будет несколько классов с интерфейсом ISelectable на один DataManager на разные случаи. И я недопонял?
Много кода получается. Неплохо было-бы совместить DataManager и интерфейсы в одном классе. Уточню, что DataManager — это не DataAccess, это просто класс для получения данных и монипулирования ими. Например, в моем случае — это просто обертка над прокси, сгенеренными средой для WebService'ов.
S>> А насчет связей не совсем понял. Используются методы PresentationLayer и ни каких других слоев больше не упоминается. S>>Схема такая: IB>А к модели и с DAL-ом у тебя кто обращается?
DAL у меня вообще в другом звене (Application tier). А про роль DataManager'а я написал выше. Не удачно я его назвал здесь, в проекте он называется Presenter (тот самый хелпер), как я уже упоминал где-то в этом топике.
Напомню свой случай:
Здравствуйте, Mike Chaliy, Вы писали:
MC>А с чего вы взяли что она в домене? Что ее не придеться подгружать? Ткните ка меня носом. А то чета не могу найти инфы по этому поводу.
Что и как компилируется можно посмотреть например, здесь
Классы из App_Code всегда доступны для использования страницами, т.к. она компилируется раньше, reference на нее автоматически добавляется для всех as*x. Потом компилируются страницы, и одна не видит другую, т.к. они в разных сборках и у них нет reference друг на друга.
Про домен и подгрузку не понял вопроса. Происходит процедура, практически аналогичная вызову компилятора с reference на уже скомпилированную сборку из App_Code. Причем, можно указать в конфигурационном файле чтобы поддиректории App_Code компилировались в разные сборки, тогда референс будет стоять на все получившиеся сборки.
And please don't stick Thy servants, Lord, in a Rotissomat.
Здравствуйте, Sacode, Вы писали:
S>Ну я и говорю, что получается будет несколько классов с интерфейсом ISelectable на один DataManager на разные случаи.
Можно и так, но, но такая ситуация редка. Собственно сейчас ровно тоже самое, когда с ODS работаешь.
Вообще, поскольку за создание класса-обертки ты отвечаешь сам, то при создании можешь определить стратегию работы обертки с DataManager-ом, ну и реализовать одну обертку с несколькими стратегиями, если нужно.
S>Много кода получается. Неплохо было-бы совместить DataManager и интерфейсы в одном классе.
Ну совмести, хотя я бы наверное разнес, впрочем от ситуации зависит.
Здравствуйте, IB, Вы писали:
MC>>И еще раз подчеркну что ОДС не ссылаеться никуда. Там храниться строка, по кторой обьект достаеться только в момент DataBind. IB>Замечательно. Так в чем разница, указывается в этой строке произвольный тип или тип реализующий конкретный набор интерфейсов?
Тут у вас какое-то непонимание по поводу присутствия нужных типов на момент компиляции приложения. Абстрагируясь от App_Code, если сделать reference на Class Library Project, уж он то точно будет доступен.
MC>>Я просто к чему подвожу. К универсальности решения. IB>Решение с интерфейсами более универсально, оно не требует обязательного присутствия ODS в aspx.
+1
MC>> Микрософт сдела фактори для создания обьектов. Я не вижу причины по которой не использовать собтвенно эту фактори? IB>Я вижу — эта фабрика не типизирована и привязана к aspx.
+1.
З.Ы. ODS — это такой экспресс-враппер, сделанный для того чтобы быстро клепать небольшие приложения и не испугать новичков интерфейсами и прочей фигней Если у вас большое приложение, то там все будет уже написано в DAL, использовано в BL. В принципе можно обернуть BL в ODS и использовать в UI, если надо приклепать по-быстренькому сбоку. Если по-хорошему, то будет своя реализация, будь то MVC или MVP, или еще чтото, и ODS в этой модели просто лишний.
Моя смерть ездит в черной машине с голубым огоньком
Здравствуйте, Gollum, Вы писали:
G>З.Ы. ODS — это такой экспресс-враппер, сделанный для того чтобы быстро клепать небольшие приложения и не испугать новичков интерфейсами и прочей фигней
Так-то оно так, но вот только в ODS есть часть функционала, который ручками реализуется муторно и некрасиво.
Здравствуйте, IB, Вы писали:
G>>З.Ы. ODS — это такой экспресс-враппер, сделанный для того чтобы быстро клепать небольшие приложения и не испугать новичков интерфейсами и прочей фигней IB>Так-то оно так, но вот только в ODS есть часть функционала, который ручками реализуется муторно и некрасиво.
Здравствуйте, Gollum, Вы писали:
G>Здравствуйте, IB, Вы писали:
MC>>>И еще раз подчеркну что ОДС не ссылаеться никуда. Там храниться строка, по кторой обьект достаеться только в момент DataBind. IB>>Замечательно. Так в чем разница, указывается в этой строке произвольный тип или тип реализующий конкретный набор интерфейсов?
G>Тут у вас какое-то непонимание по поводу присутствия нужных типов на момент компиляции приложения. Абстрагируясь от App_Code, если сделать reference на Class Library Project, уж он то точно будет доступен.
Еще раз. При использовании интрфейсов в коде страницы они в месте с Апп_Коде будут подгружены в домен приложения. Если ссылок на эти интерфейсы в странице небудет. То ничего никуда пожгружаться не будет.
Может быть небудем громко заявлять о моем неразбирании, а вы или разберетесь с механизмами компиляции в асп.нет или обьясните мне где я заблуждаюсь.
G>З.Ы. ODS — это такой экспресс-враппер, сделанный для того чтобы быстро клепать небольшие приложения и не испугать новичков интерфейсами и прочей фигней Если у вас большое приложение, то там все будет уже написано в DAL, использовано в BL. В принципе можно обернуть BL в ODS и использовать в UI, если надо приклепать по-быстренькому сбоку. Если по-хорошему, то будет своя реализация, будь то MVC или MVP, или еще чтото, и ODS в этой модели просто лишний.
Попахивает програмированием ради програмирования — неболее. Вы лучше минусы назовите. Например для минус в том что его неззя использовать из кода — минусом неявляються вовсе.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Mike Chaliy, Вы писали:
MC>>И еще раз подчеркну что ОДС не ссылаеться никуда. Там храниться строка, по кторой обьект достаеться только в момент DataBind. IB>Замечательно. Так в чем разница, указывается в этой строке произвольный тип или тип реализующий конкретный набор интерфейсов?
Странно или есть ссылка на интрфейс из Апп_Код или нет. Для вас в контексте разговара про BuildManager нет никакой разницы?
MC>>Я просто к чему подвожу. К универсальности решения. IB>Решение с интерфейсами более универсально, оно не требует обязательного присутствия ODS в aspx.
Можно разговаривать не про ОДС. Через єтот механизм создаеться все включая странички.
MC>> Микрософт сдела фактори для создания обьектов. Я не вижу причины по которой не использовать собтвенно эту фактори? IB>Я вижу — эта фабрика не типизирована и привязана к aspx.
Нетипизирована, потому что кроме обьектов могут создаваться странички, темы, скины, ваши кастомные что-то. Вобщемто все на что есть BuildProvider. Другого способа нет. Менеджеру необходимо знать что компилить. Для того чтобы задать путь, тип самым универсальным спосбом явлеться строка. Его можно было бы обернуть во чтонить по типу Ури. Но иммет ли это смысл? Это уже другой вопрос. Типизированноси от этого не прибавилось. Для типизированости надо все скомпилить. Схема компиляции такова что именно инраструктура асп.нет следит за компиляцией.
Гы, чейто она привязана? Мы же про BuildManagr говорим?
Здравствуйте, Gollum, Вы писали:
G>Здравствуйте, IB, Вы писали:
G>>>З.Ы. ODS — это такой экспресс-враппер, сделанный для того чтобы быстро клепать небольшие приложения и не испугать новичков интерфейсами и прочей фигней IB>>Так-то оно так, но вот только в ODS есть часть функционала, который ручками реализуется муторно и некрасиво.
G>Написать своего наследника DataSourceControl?
IB нехочет испольщовать из дизанера. Не из дизайнера придеться еще и доробатывать ГридВью. В часноти переопределить GetDataSource и GetData. Иначе все датасоурсы оборачиваються в ReadOnlyDataSource.
Вобщемто я рад что у меня нет страха перед дизайнерами.
Здравствуйте, Gollum, Вы писали:
G>Здравствуйте, Mike Chaliy, Вы писали:
MC>>А с чего вы взяли что она в домене? Что ее не придеться подгружать? Ткните ка меня носом. А то чета не могу найти инфы по этому поводу.
G>Что и как компилируется можно посмотреть например, здесь G>Классы из App_Code всегда доступны для использования страницами, т.к. она компилируется раньше, reference на нее автоматически добавляется для всех as*x. Потом компилируются страницы, и одна не видит другую, т.к. они в разных сборках и у них нет reference друг на друга.
Да. Ну так пропаблишите(незабудте галочку поставить про то что контент был неапдейченый, иначе он скомпили тока предварительный класс) страничку в кторой ОДС используеться в дизайн тайме. А потом найдите референс нв Апп_Коде. Как найдете отпишитесь.
G>Про домен и подгрузку не понял вопроса. Происходит процедура, практически аналогичная вызову компилятора с reference на уже скомпилированную сборку из App_Code. Причем, можно указать в конфигурационном файле чтобы поддиректории App_Code компилировались в разные сборки, тогда референс будет стоять на все получившиеся сборки.
Я думаю вы этот вопрос лучше поймете, когда не найдете реферонсов на Апп_Коде. Более того рефренс на собрку никогда не означает ее подгрузку в домен.
Здравствуйте, Mike Chaliy, Вы писали:
MC>Здравствуйте, Gollum, Вы писали:
G>>Здравствуйте, IB, Вы писали:
G>>>>З.Ы. ODS — это такой экспресс-враппер, сделанный для того чтобы быстро клепать небольшие приложения и не испугать новичков интерфейсами и прочей фигней IB>>>Так-то оно так, но вот только в ODS есть часть функционала, который ручками реализуется муторно и некрасиво.
G>>Написать своего наследника DataSourceControl?
MC>IB нехочет испольщовать из дизанера. Не из дизайнера придеться еще и доробатывать ГридВью. В часноти переопределить GetDataSource и GetData. Иначе все датасоурсы оборачиваються в ReadOnlyDataSource.
MC>Вобщемто я рад что у меня нет страха перед дизайнерами.
Здравствуйте, Mike Chaliy, Вы писали:
MC>Странно или есть ссылка на интрфейс из Апп_Код или нет.
Ее в любом случае нет. Меня не интересует как aspx будет узнавать о наличии нужного адаптера, хоть голубиной почтой, мне важна возможность пользоваться функционалом без aspx и BuildManager-а. В aspx-е все останется по прежнему.
MC>Для вас в контексте разговара про BuildManager нет никакой разницы?
Так. На словах не доходит, пробую на примере, следите за руками:
То как есть сейчас:
.....cs
public class Adapter
{
IEnumerable SelectMethod()
{
}
}
.....aspx
<asp:ObjectDataSource ... SelectMethod="SelectMethod" TypeName="Adapter">
То, о чем говорю я:
.....cs
public class Adapter : ISelectable
{
IEnumerable ISelectable.SelectMethod()
{
}
}
// использовать можно в .cs - файле
//
GridView.SetSelectable = Adapter;
// Или, если очень хочется использовать .aspx, то можно по старинке
//
.....aspx
<asp:ObjectDataSource ... TypeName="Adapter">
Во втором случае в ObjectDataSource содержится та же строка SelectMethod="SelectMethod", но указывать ее явно нет необходимости, так как нужный класс обязан реализовывать соответствующий интерфейс, тем самым все имена методов известны заранее.
С точки зрения пользования BuildManager разницы между этими двумя способами нет. Но во втором случае была бы возможность пользоваться функционалом ODS и без участия aspx.
MC>Можно разговаривать не про ОДС. Через єтот механизм создаеться все включая странички.
Можно, но мы сейчас говорим именно про ODS и про возможности которые он предоставляет.
MC>Нетипизирована, потому что кроме обьектов могут создаваться странички, темы, скины, ваши кастомные что-то.
Это все тоже объекты, но дело не в этом. Мне непонятно, почему сначала не была сделана типизированная фабрика для всех объектов, которые можно задать типизировано, а уже поверх этого сделать нетипизированный механизм для пользования из aspx?
Здравствуйте, Mike Chaliy, Вы писали:
MC>Вобщемто я рад что у меня нет страха перед дизайнерами.
В восемдесят пятый раз объясняю. Дело не в дизайнере, а в том, что ODS работает с не типизированными строками, вместо объектов и возможности использовать его функционал типиировано — нет. Дизайнеру все фиолетово, он может генерить совершенно произвольный код, в любое место приложения, как напишешь.
Здравствуйте, Mike Chaliy, Вы писали:
MC>Еще раз. При использовании интрфейсов в коде страницы они в месте с Апп_Коде будут подгружены в домен приложения. MC>Если ссылок на эти интерфейсы в странице небудет. То ничего никуда пожгружаться не будет.
Что вы понимаете под "ссылками"? Reference на App_Code есть у всех страниц. Типы из App_Code всегда им доступны.
MC>Может быть небудем громко заявлять о моем неразбирании,
??? Никто такого не заявлял. Просто я не могу вообще понять о чем идет речь.
MC>Попахивает програмированием ради програмирования — неболее. Вы лучше минусы назовите.
Так Иван назвал уже минусы, основной из них слабая типизация.
Здравствуйте, Mike Chaliy, Вы писали:
MC>Да. Ну так пропаблишите(незабудте галочку поставить про то что контент был неапдейченый, иначе он скомпили тока предварительный класс) страничку в кторой ОДС используеться в дизайн тайме. А потом найдите референс нв Апп_Коде. Как найдете отпишитесь.
Я окончательно перестал что-либо понимать. Референс — это практически ключ с которым компилятор вызывается. Где я должен его искать, когда все уже спкомпилировано (в режиме publish)? И если бы его не было, как бы я на страницах использовал типы из App_Code?
MC>Более того рефренс на собрку никогда не означает ее подгрузку в домен.
Это вообще к чему? При чем тут рантайм, мы же про компиляцию говорим.
И начальник заставы поймет меня, и беспечный рыбак простит
MC>Еще раз. При использовании интрфейсов в коде страницы они в месте с Апп_Коде будут подгружены в домен приложения. Если ссылок на эти интерфейсы в странице небудет. То ничего никуда пожгружаться не будет.
Не понимаю, в чем проблема "подгрузки интерфейсов"? Также не совсем понимаю при чем тут App_Code вообще.
Что-то вы куда-то не тудв уже ушли. Какое это все имеет отношение к ODS,
MC>Попахивает програмированием ради програмирования — неболее. Вы лучше минусы назовите. Например для минус в том что его неззя использовать из кода — минусом неявляються вовсе.
Похоже небыло у тебя проектов больших.
Как минимум проблемы следующие:
1. Нетипизирован — следовательно нет контроля за всеми этими строками и пр. кухней со стороны компилятора. Как следствие меняем название класса/метода, все компилируется, но не работает. Не говоря уже про написанную невозможность Find Usages.
2. Он контрол, т.е. обязательно требует наличия страницы ASPX. Использование паттерна MVC/MVP вызывает определенные трудности.
3. Производительность. ODS из-за своей нетипизированности внутри использует Reflection. Не самая быстрая вещь...
4. То, как у него задаются параметры методов — это вообще темя садо-мазо. Для того чтобы передать в метод значение свойства страницы надо делать кульбит с ControlParameter.
5. Еще?
Думаю было-бы достаточно только первого пункта для ритуального сожжения.
Здравствуйте, Sacode, Вы писали:
S>Не понимаю, в чем проблема "подгрузки интерфейсов"? Также не совсем понимаю при чем тут App_Code вообще. S>Что-то вы куда-то не тудв уже ушли. Какое это все имеет отношение к ODS,
+1!!!
S>Думаю было-бы достаточно только первого пункта для ритуального сожжения.
Кто хочет написать нормальный?
Здравствуйте, Gollum, Вы писали:
G>Здравствуйте, Mike Chaliy, Вы писали:
MC>>Да. Ну так пропаблишите(незабудте галочку поставить про то что контент был неапдейченый, иначе он скомпили тока предварительный класс) страничку в кторой ОДС используеться в дизайн тайме. А потом найдите референс нв Апп_Коде. Как найдете отпишитесь.
G>Я окончательно перестал что-либо понимать. Референс — это практически ключ с которым компилятор вызывается. Где я должен его искать, когда все уже спкомпилировано (в режиме publish)? И если бы его не было, как бы я на страницах использовал типы из App_Code?
Пропаблишите сайт. Рефлетором откройте сборку страницы. Ненравиться рефлектор откройте чем то другим. Что показывает референсы.
А то как бы вы использовали типы из Апп_Кода, и являеться сутью разговора. Когда вы используете BuildManager Апп_Коде подгружаеться динамически когда она нужна. И если она ненужнв она не подгружаеться. Когда же в вашей странице прямая ссылка на тип из Апп_Коде, то она подгружаеться ВСЕГДА.
MC>>Более того рефренс на собрку никогда не означает ее подгрузку в домен. G>Это вообще к чему? При чем тут рантайм, мы же про компиляцию говорим.
Хы. И причем тут тогда подгрузка в домен? Помойму мы разговариваем про подгрузку ассембли в домен. Причем уже давно. С того момента как вы ответили. Я в каждом посте использую ту или иную версию выражения "подгружать сборку". Помойму довольно очевидно.
Здравствуйте, IB, Вы писали:
IB>Во втором случае в ObjectDataSource содержится та же строка SelectMethod="SelectMethod", но указывать ее явно нет необходимости, так как нужный класс обязан реализовывать соответствующий интерфейс, тем самым все имена методов известны заранее. IB>С точки зрения пользования BuildManager разницы между этими двумя способами нет. Но во втором случае была бы возможность пользоваться функционалом ODS и без участия aspx.
Я так понял спорит бесполезно, я щас в сотый раз обьясню почему сделано так, а вы сотый раз это проигнорируете и покажите еще один из десятков возможных реализаций. Вы хоть попробовали пропаблишить? Ну хоть чтото попробовать из того что я приводил в качесте пирмеров. Вобщемто поговорили, я так понимаю сотый раз не нужен...
MC>>Нетипизирована, потому что кроме обьектов могут создаваться странички, темы, скины, ваши кастомные что-то. IB>Это все тоже объекты, но дело не в этом. Мне непонятно, почему сначала не была сделана типизированная фабрика для всех объектов, которые можно задать типизировано, а уже поверх этого сделать нетипизированный механизм для пользования из aspx?
Я уже дисяток раз обьяснил почему она нетипизирована. Вы же не типизируете урлы. Так и тут это просто опиматель обьекта.
Здравствуйте, Sacode, Вы писали:
S>Не понимаю, в чем проблема "подгрузки интерфейсов"? Также не совсем понимаю при чем тут App_Code вообще. S>Что-то вы куда-то не тудв уже ушли. Какое это все имеет отношение к ODS,
Туда-туда. Есть маштабируемость приложений. Есть большое количество аджакс кода. Есть сотояния страницы в которых отсутвует необходимость ссылок на Апп_Коде и соответвенно ее подгрузки в домен. И именно нетипизрованный ОДС это лучше всего потдерживает.
S>Похоже небыло у тебя проектов больших.
Ах ну да тут же профи собрались... Куда там мне...
Здравствуйте, Mike Chaliy, Вы писали:
MC>Пропаблишите сайт. Рефлетором откройте сборку страницы. Ненравиться рефлектор откройте чем то другим. Что показывает референсы.
Посмотрел. Есть.
MC>А то как бы вы использовали типы из Апп_Кода, и являеться сутью разговора. Когда вы используете BuildManager Апп_Коде подгружаеться динамически когда она нужна. И если она ненужнв она не подгружаеться. Когда же в вашей странице прямая ссылка на тип из Апп_Коде, то она подгружаеться ВСЕГДА.
Так в чем поблема-то?
MC>Хы. И причем тут тогда подгрузка в домен? Помойму мы разговариваем про подгрузку ассембли в домен. Причем уже давно. С того момента как вы ответили. Я в каждом посте использую ту или иную версию выражения "подгружать сборку". Помойму довольно очевидно.
Так я и не понимаю что мешает ее загрузить?
Давайте по-другому. Я так понимаю, что речь идет о недоступности типа из App_Code в какой-то момент времени. Напишите когда я не смогу им пользоваться, я приведу контр-пример.
З.Ы. Может я вас чем-то обидел, я извиняюсь. Только я правда не понимаю сути вопроса.
Здравствуйте, Mike Chaliy, Вы писали:
MC>Я так понял спорит бесполезно,
Спорить, в принципе занятие бесполезное. Надо пытаться понять, а не всеми силами доказать свою правоту, думая что никто ни в чем не разбирается.
MC> я щас в сотый раз обьясню почему сделано так, а вы сотый раз это проигнорируете и покажите еще один из десятков возможных реализаций.
Я прекрасно понял Ваши объяснения, но ущербность такого решения они не оправдывают. Я привел решение, которое полностью подходит под описанные Вами условия компиляции, используется ровно тот же самый BuildManager с тем же самым эффектом. Есть объяснение, почему нельзя было сделать так?
MC> Вы хоть попробовали пропаблишить?
Что пропаблишить?! aspx код в обоих ситуациях тот же, просто во втором случае нет необходимости его использовать. Я уже даже пример в коде привел, в русском языке разочаровавшись. Если что непонятно, могу еще пояснить, только спросите что неясно...
MC>Я уже дисяток раз обьяснил почему она нетипизирована.
Блин. Я знаю почему она не типизирована, более того, меня это просто не волнует и в данном случае не имеет никакого значения. Я не понимаю почему нельзя было сделать типизировано, а поверх этого сделать не типизировано. Вы можете объяснить почему?
Здравствуйте, Mike Chaliy, Вы писали:
MC>>>Еще раз. При использовании интрфейсов в коде страницы они в месте с Апп_Коде будут подгружены в домен приложения. Если ссылок на эти интерфейсы в странице небудет. То ничего никуда пожгружаться не будет.
S>>Не понимаю, в чем проблема "подгрузки интерфейсов"? Также не совсем понимаю при чем тут App_Code вообще. S>>Что-то вы куда-то не тудв уже ушли. Какое это все имеет отношение к ODS,
MC>Туда-туда. Есть маштабируемость приложений. Есть большое количество аджакс кода. Есть сотояния страницы в которых отсутвует необходимость ссылок на Апп_Коде и соответвенно ее подгрузки в домен. И именно нетипизрованный ОДС это лучше всего потдерживает.
Сборка загружается в домен один раз, и занимает там свои условные 50 килобайт. Не понимаю в чем проблема один раз за несколько месяцев работы приложения потратить доли секунды и 50Кб на загрузку в домен еще одно сборки?! Кстати, ты представляешь сколько сборок так уже загружено?
К тому же твой ODS в конце концов все равно загрузит сборку, только возможно в другое время, вот и вся разница.
G>>>>З.Ы. ODS — это такой экспресс-враппер, сделанный для того чтобы быстро клепать небольшие приложения и не испугать новичков интерфейсами и прочей фигней Если у вас большое приложение, то там все будет уже написано в DAL, использовано в BL. В принципе можно обернуть BL в ODS и использовать в UI, если надо приклепать по-быстренькому сбоку. Если по-хорошему, то будет своя реализация, будь то MVC или MVP, или еще чтото, и ODS в этой модели просто лишний.
MC>>>Попахивает програмированием ради програмирования — неболее. Вы лучше минусы назовите. Например для минус в том что его неззя использовать из кода — минусом неявляються вовсе. MC>Проблемы вообще коментировать не буду.
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 напрямую стараюсь не использовать, предпочитаю серверные контролы.