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

G>З.Ы. ODS — это такой экспресс-враппер, сделанный для того чтобы быстро клепать небольшие приложения и не испугать новичков интерфейсами и прочей фигней
Так-то оно так, но вот только в ODS есть часть функционала, который ручками реализуется муторно и некрасиво.

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

G>>З.Ы. ODS — это такой экспресс-враппер, сделанный для того чтобы быстро клепать небольшие приложения и не испугать новичков интерфейсами и прочей фигней
IB>Так-то оно так, но вот только в ODS есть часть функционала, который ручками реализуется муторно и некрасиво.

Написать своего наследника DataSourceControl?

Здравствуйте, 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>Вобщемто я рад что у меня нет страха перед дизайнерами.

Уматно )

ObjectDataSource dataSource = new ObjectDataSource();
this.Controls.Add(dataSource);

dataSource.ID = "EmployeesDataSource";
dataSource.OldValuesParameterFormatString = "original_{0}";
dataSource.SelectMethod = "GetEmployes";
dataSource.TypeName = "EmployeesDataAdapter";
dataSource.EnablePaging = true;
dataSource.MaximumRowsParameterName = "pageSize";
dataSource.SelectCountMethod = "GetEmployeesCount";
dataSource.StartRowIndexParameterName = "startIndex";

Parameter sortParameter = new Parameter();
dataSource.SelectParameters.Add(sortParameter);

sortParameter.Name = "srotExpression";
sortParameter.Type = TypeCode.String;

this.GridView1.DataSourceID = dataSource.ID;

Работает. Проблема в том что всерано придеться

Здравствуйте, 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>Более того рефренс на собрку никогда не означает ее подгрузку в домен.
Это вообще к чему? При чем тут рантайм, мы же про компиляцию говорим.

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


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, Вы писали:

S>>Думаю было-бы достаточно только первого пункта для ритуального сожжения.
G>Кто хочет написать нормальный?

Я в этой ветке уже высказывался за это и даже были получены предложения от Ивана.
Re[9]: Как использовать ObjectDataSource

Автор: IB
Дата: 16.08.06

Здравствуйте, 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>Проблемы вообще коментировать не буду.

Почему? Это же и есть основная тема спора.