Re[4]: Как использовать ObjectDataSource - ASP.NET

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

MC>Все что дальше не относиться к предыдущей беседе. Так как уже признал что НЕПРАВ.
Ок, проехали...

MC> Я ж так понял его должен реализовывать адаптер бизнес обектов. Гы. А если я захочу поменять сигнатуру метода?
А зачем?

MC> Или заставить всех писать бизнес обьекты с четырмя методами? Или позаставлять всех делать фактори?
Тут уже от конкретной ситуации зависит. Смысл в том, что для пэйджинга надо подпихнуть реализацию соответствующего интерфейса, кто и как это будет делать — дело десятое. По сути это ровно то что делает ODS, но я не прикован к aspx и все типизировано.

MC> Кстити я ж так понял вы будет реализовывать свой дата соурсе.
Пока нет, это я просто плакался на майкрософтовский...

MC>Предложите свою реализацию.
Сгладить проблему "в лоб" можно так:
Описать соответствующие интерфейсы типа IPageable, ISortable, ICacheable, ect...
Реализовтаь эти интерфейсы в обертке или самом объекте.
Заставить общаться контрол с объектом через эти интерфейсы, например реализовав своего наследника IDataSource.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

MC>>Предложите свою реализацию.
IB>Сгладить проблему "в лоб" можно так:
IB>Описать соответствующие интерфейсы типа IPageable, ISortable, ICacheable, ect...
IB>Реализовтаь эти интерфейсы в обертке или самом объекте.
IB>Заставить общаться контрол с объектом через эти интерфейсы, например реализовав своего наследника IDataSource.

Собственно это понятно. Я имею ввиду поставьте себя на место микрософтовцев. Ну они в курсе что кроме таких людей как вы есть такие люди как я, которые без дизанеров жить не могут. Плюс проблема которую описал Sacode (Это я про несколько слект методов в одном дата обьекте). Вобщемто предположим что вам надо добиться максимальной отдачи при минмальных затратах. На какой реализации вы бы остановились?

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

S>Вроде нет. Сам же прежлагал сделать реализацию интерфейсов отдельно, а потом обернуть все это в контрол, чтобы можно было пользоваться дизайнером.
Да, но я не о том. Я к тому, что если мне, например, дизайнером пользоваться не надо, то я все равно вынужден лезть в aspx код и описывать этот контрол там.

S>Не. Вопрос как отобразить класс работы с данными на эти интерфейсы. Вот тут и начинаются сложности...
S>Методов извлечения данных несколько GetAllEntities, GetEntitiesByName и пр., а в интерфейсе ISelect будет однин метод Select.
S>Вот и вопрос какими при этом должны быть интерфейсы?
Ааа... Приерно так:

// Ну это понятно
//
ISelect
{
    IEnumerable Select();
}

// постраничная выборка
//
IPagable
{
    IEnumerable SelectPage(int PageNum, int PageSize, out int TotalCount);
}

// Кеширование
//
ICachable
{
    void Add<T>(string Key, T CacheObject)
    T Get<T>(string Key)
    void ClearCache();
  ICacheStrategy CacheStrategy { get; set; }    
}
    
// Сортировка
//
ISortable
{
    void Sort(string SortExpression)
}

//Обновление
//
IUpdatable
{
        void Update<T>(T BizObject);
}

Далее реализуем обертку:

public class BindAdapter : IPagable, ICachable, ISortable, IUpdatable
{
    ...
    
    private string _sortExpression  = "";
    void Sort(string SortExpression)
    {
        _sortExpression = SortExpression;
    }
    
    IEnumerable SelectPage(...)
    {
        TotalCount = DataManager.GetAllEntitiesCount();
        return DataManager.GetAllEntities(maximumRows, startRowIndex, _sortExpression);
    }
    
    ....
}

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

Строго говоря, описывать сортировку и фильтрацию острой необходимости нет, так как класс создаешь ты сам и при инициализации все необходимые параметры можешь передать в обертку в нужном тебе виде.
Каким именно способом тебе реализовать тот или иной интерфейс пользуясь возможностями DataManager, опять-таки определяешь в адаптере — ему все известно.

S>Похже чем-то на MVC/MVP, только без интерфейсов и PresentationLogic ничего не знает о представлении, даже интерфейса, только страница ASPX знает и о модели и о PresentationLogic.
Ага, значит PresentationLogic — это просто хелпер, который содержит большинство общего функционала, я писал о таком подходе...
Это тестируется хуже чем MVP и вью по прежнему перегружен знаниями о модели и разруливанием связей между слоями.

S>Может распишешь как сделал?
По разному. В одном случае просто обертка над ODS, для пейджинга, а во втором пара классов-хелперов для двунаправленного байндинга, без использования ODS, там все примитивненько, благо больше не требовалось.

S>Давай, у нас грядет небольшой рефакторинг этой части, как раз будет кстати.

См. выше.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

MC> Плюс проблема которую описал Sacode (Это я про несколько слект методов в одном дата обьекте).
Какой select метод из объекта использовать — определяет адаптер — тот класс, который реализует интерфейс. Это ровно тоже самое, чтоприходится делать сейчас при использовании ODS.

MC>Вобщемто предположим что вам надо добиться максимальной отдачи при минмальных затратах. На какой реализации вы бы остановились?
Я бы реализовал все через интерфейсы, а поверх бы этого прикрутил ODS для дизайнеров. Дело в том, что они все равно используют некие соглашения по клиентскому коду (при использовании ODS мы должны указать тип и его методы). И проблем задекларировать эти соглашения в явном виде через интерфейсы нет. В этом случае был бы единый механизм и для тех кто хочет использовать дизайнер идля тех кому он не нужен, сейчас же тем, кому дизайнер не нужен, приходится реализовывать руками то, что уже реализовано в MS.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

S>>Не. Вопрос как отобразить класс работы с данными на эти интерфейсы. Вот тут и начинаются сложности...
S>>Методов извлечения данных несколько GetAllEntities, GetEntitiesByName и пр., а в интерфейсе ISelect будет однин метод Select.
S>>Вот и вопрос какими при этом должны быть интерфейсы?
IB>Ааа... Приерно так:
IB>

IB>// Ну это понятно
IB>//
IB>ISelect
IB>{
IB>    IEnumerable Select();
IB>}

IB>// постраничная выборка
IB>//
IB>IPagable
IB>{
IB>    IEnumerable SelectPage(int PageNum, int PageSize, out int TotalCount);
IB>}

IB>// Кеширование
IB>//
IB>ICachable
IB>{
IB>    void Add<T>(string Key, T CacheObject)
IB>    T Get<T>(string Key)
IB>    void ClearCache();
IB>  ICacheStrategy CacheStrategy { get; set; }    
IB>}
    
IB>// Сортировка
IB>//
IB>ISortable
IB>{
IB>    void Sort(string SortExpression)
IB>}

IB>//Обновление
IB>//
IB>IUpdatable
IB>{
IB>        void Update<T>(T BizObject);
IB>}
IB>

IB>Далее реализуем обертку:
IB>

IB>public class BindAdapter : IPagable, ICachable, ISortable, IUpdatable
IB>{
IB>    ...
    
IB>    private string _sortExpression  = "";
IB>    void Sort(string SortExpression)
IB>    {
IB>        _sortExpression = SortExpression;
IB>    }
    
IB>    IEnumerable SelectPage(...)
IB>    {
IB>        TotalCount = DataManager.GetAllEntitiesCount();
IB>        return DataManager.GetAllEntities(maximumRows, startRowIndex, _sortExpression);
IB>    }
    
IB>    ....
IB>}
IB>

IB>В классе, который реализует байндинг пришуся методы, которые принимают описанные интерфейсы и этот класс смотрит какие интерфейсы в наличии и работает через них.

Дык вопрос в том, что при таком подходе в классе может быть только один метод Select, а в изначальном классе их три. Получается, что нужно делать три класса, по одному на каждый метод выборки. Или делать класс, который бы описывал метод и его параметры со значениями (типа паттерна Command) и его уже передавать методу Select.
Вот тут порыться еще надо...

S>>Похже чем-то на MVC/MVP, только без интерфейсов и PresentationLogic ничего не знает о представлении, даже интерфейса, только страница ASPX знает и о модели и о PresentationLogic.
IB>Ага, значит PresentationLogic — это просто хелпер, который содержит большинство общего функционала, я писал о таком подходе...
IB>Это тестируется хуже чем MVP и вью по прежнему перегружен знаниями о модели и разруливанием связей между слоями.

Насчет модели — да. Но по-моему напрасно стараться этого избежать — колонки, байндинг и пр. все-равно будут. А насчет связей не совсем понял. Используются методы PresentationLayer и ни каких других слоев больше не упоминается.
Схема такая:

- ASPX ---------------------    - PresentationLogic --------------------------------    - Вне приложения -
GridView -> ObjectDataSource -> PresentationLogic.EntityPresenter -> WebServiceProxy -> WebService -> ...

Презентером (класс EntityPresenter) он у нас назван исторически, когда еще MVP не был так хорошо известен.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, 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-ом у тебя кто обращается?

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

G> Вы же не возмущаетесь, что в странице можно использовать SqlDataSource?
Я? Я-то как раз возмущаюсь, поубивав-бы..

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

MC> В случае с реализацией через интрфейс код из App_Code нужен всегда.
Да он и так всегда нужен, даже при текущей схеме. Как только дело доходит до ODS он вынужден поднимать мой класс-обертку из код-бихаинда.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

MC>> В случае с реализацией через интрфейс код из App_Code нужен всегда.
IB>Да он и так всегда нужен, даже при текущей схеме. Как только дело доходит до ODS он вынужден поднимать мой класс-обертку из код-бихаинда.

Я вообщето привел пример с аджаксом которому ненужны данные. Ну например генерация календаря. Это все на одной страничке. Есть грид юзающий ОДС и календарик ничего не юзающий. Грид использует колбеки для пейджинга, а календарик для того чтобы перерендериться например при изменении месяца. Это синтетический пример. Суть не в нем. Суть в вопросе (повторюсь): Может быть всетаки лучше отдать прерогативу создания обьектов инраструктуре асп.нета?

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

MC>Суть в вопросе (повторюсь): Может быть всетаки лучше отдать прерогативу создания обьектов инраструктуре асп.нета?
Да байта ради, наличие интерфейса тут ничего не изменит. В одном случае ODS ссылается на произвольный класс, в другом на класс реализующий определенный набор интерфейсов, с точки зрения компиляции разницы никакой.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

MC>>Суть в вопросе (повторюсь): Может быть всетаки лучше отдать прерогативу создания обьектов инраструктуре асп.нета?
IB>Да байта ради, наличие интерфейса тут ничего не изменит. В одном случае ODS ссылается на произвольный класс, в другом на класс реализующий определенный набор интерфейсов, с точки зрения компиляции разницы никакой.

Вы не ответели на мой вопрос. Я не говорю про часный случай когда странице в любом ее состоянии нужны данный. Существуют состояния когда ей данные ненужны (я уже обрисовывал синтетическую ситуацию с колбеками, могу даже пример привести, например каледнадрик генерящийся на сервреи отдающейся через колбеки).

И еще раз подчеркну что ОДС не ссылаеться никуда. Там храниться строка, по кторой обьект достаеться только в момент DataBind.

И еще. Уже речь не идет про компиляцию. Как правилно заметил Gollum App_Code компилиться всегда. Теперь уже речь идет о подгрузки Апп_Коде в домен. Опять же про ситуацию когда по какойто причине на момент колбека Апп_Коде в домен не подгружена.

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

).

С другой стороны я не вижу ограничений и на прямое создание обьекта. Мои примеры достаточно синтетически. Да и к томуже затратами на подгрузку Апп_Кода можно пренебречь.

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

MC>Вы не ответели на мой вопрос.
Ответил.

MC>И еще раз подчеркну что ОДС не ссылаеться никуда. Там храниться строка, по кторой обьект достаеться только в момент DataBind.
Замечательно. Так в чем разница, указывается в этой строке произвольный тип или тип реализующий конкретный набор интерфейсов?

MC>Я просто к чему подвожу. К универсальности решения.
Решение с интерфейсами более универсально, оно не требует обязательного присутствия ODS в aspx.

MC> Микрософт сдела фактори для создания обьектов. Я не вижу причины по которой не использовать собтвенно эту фактори?
Я вижу — эта фабрика не типизирована и привязана к aspx.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

S>>Дык вопрос в том, что при таком подходе в классе может быть только один метод Select, а в изначальном классе их три. Получается, что нужно делать три класса, по одному на каждый метод выборки.
IB>Зачем? У тебя же не стоит задача обязательно воспользоваться всеми методами DataManager, твоя задача — реализовать необходимый набор интерфейсов корректного байнднинга, ну и что, что при этом не все возможности DataManager будут использованы?

Ну я и говорю, что получается будет несколько классов с интерфейсом ISelectable на один DataManager на разные случаи. И я недопонял?
Много кода получается. Неплохо было-бы совместить DataManager и интерфейсы в одном классе. Уточню, что DataManager — это не DataAccess, это просто класс для получения данных и монипулирования ими. Например, в моем случае — это просто обертка над прокси, сгенеренными средой для WebService'ов.

S>> А насчет связей не совсем понял. Используются методы PresentationLayer и ни каких других слоев больше не упоминается.
S>>Схема такая:
IB>А к модели и с DAL-ом у тебя кто обращается?

DAL у меня вообще в другом звене (Application tier). А про роль DataManager'а я написал выше. Не удачно я его назвал здесь, в проекте он называется Presenter (тот самый хелпер), как я уже упоминал где-то в этом топике.
Напомню свой случай:

- ASPX ---------------------    - PresentationLogic -----------------------------------------------------------------    - Вне приложения -
GridView -> ObjectDataSource -> PresentationLogic.EntityPresenter (тот самый условный DataManager) -> WebServiceProxy -> WebService -> ...

... << RSDN@Home 1.1.4 stable rev. 510>>

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

IB>Я? Я-то как раз возмущаюсь, поубивав-бы..

И я возмущаюсь. Посмотрите на тьюториалы от MS. Это все от лукавого

And please don't stick Thy servants, Lord, in a Rotissomat.

Здравствуйте, 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 и интерфейсы в одном классе.
Ну совмести, хотя я бы наверное разнес, впрочем от ситуации зависит.

... << RSDN@Home 1.2.0 alpha rev. 0>>

Здравствуйте, 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 в этой модели просто лишний.

Моя смерть ездит в черной машине с голубым огоньком

От:	IB	http://rsdn.ru
Дата:	16.08.06 12:35
Оценка:

От:	Mike Chaliy	http://chaliy.name
Дата:	16.08.06 12:45
Оценка:

От:	IB	http://rsdn.ru
Дата:	16.08.06 13:50
Оценка:

От:	IB	http://rsdn.ru
Дата:	16.08.06 13:59
Оценка:	+1

	От:	Sacode
	Дата:	16.08.06 14:29
	Оценка: