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

MC>>Вы так и несказали какой такой механизм вам нужен не в дизайн тайме.
IB>Например, точно такой же как ODS, но на интерфейсах. Допустим, для пейджинга существовал бы интерфейс IPagableBind с методом SelectPage(PageNum, RowsPerPage) и свойством TotalCount. И если я хочу реализовать кастомный пейджинг по своей коллекции, то мне достаточно было бы реализовать этот интерфейс и подпихнуть нужный объект контролу.

Это можно сделать самому написав простенького наследника от DataSourceControl. Почему этого не сделали в MS? Думаю не очень они хотят делать все универсально — иначе партнерам ничего не достанется. К тому же здесь возникает небольшая сложность с тем, что методов извлечения данных, в отличии от методов изменения, обычно больше одного. Можно, конечно, сделать несколько классов для разных методов, но как-то это не красиво. Хотя может и поробую на днях, самого достали косяки ODS.

MC>> Разберитесь с механизмами компиляции страниц. Пропаблишите сайт. Поглядите кто куда референсица.
IB>То есть, Вы утверждаете, что для полноценного байндинга необходимо использовать именно такой подход с передачей типа в виде строковых констант?
IB>Кто там про невежество говорил?

Не вопрос не в том что лучше использовать для бандинга, а в том что будет работать как контрол на странице. На странице нет нормального способа присвоить свойству что-либо кроме строки. Вот если бы можно было написать:

<asp:ObjectDataSource ID="MyDataSource" runat="server" Type="<%= typeof(My.MyDataManager) %>" ...>...
Вот и приходится для поддержки дизайнера страниц использовать строки, а не типы. Мне кажется об этом говорил MC.

MC>>В чем заключаеться необходимость?
IB>Необходимость заключается в том, что передача типа в виде строковой переменной — крайне кривая конструкция и вообще, механизму описания байндинга не место в aspx.

Про первый пункт написал выше, а вот про второй можно и по-подробней. :) Я не спорю, я спрашиваю — где ему место?

MC>> Если вообще ненужен ОДС. Зачем тогда такая функциональность?
IB>Затем что ODS обеспечивает двунаправленый баиндинг и поддержку кастомного пэйджинга.
IB>Есть идеи как сделать это без ODS? Уже не в первый раз спрашиваю.

См. первый пункт.

MC>>А вот собственно ОДС это и есть "что угодно для помешения хтого дела в аспх".
IB>В том-то и дело, что он реализует ряд функций, который стандартный баиндинг делать не умеет.

Есть такой пункт. При всех недостатках, ObjectDataSource — это наилучший вариант из фреймворка.... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, 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. Наверняка что-то еще...... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, 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>Об чем и речь.

Может решим эту проблему? :) Мне нужно решение, но тратить на него много времени нет возможности.
Как насчет реализации интерфейсов из первого пункта?... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, 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>Могу набросать пару идей... :)

Давай, у нас грядет небольшой рефакторинг этой части, как раз будет кстати. :)... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, 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>>