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>Могу набросать пару идей...
Давай, у нас грядет небольшой рефакторинг этой части, как раз будет кстати.
Мы уже победили, просто это еще не так заметно...
). Ну а на большее у меня нервов нехватает. Вот хочеться человеку заюзать ODS и все тут. То что от него никакой функцмональности его это просто тупо не волнует (это ессно для кодебехаинда).
). Другими словами я склоняюсь к тому, что Иван прав...
.
