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

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

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

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

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

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

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

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

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

S>Ну я и говорю, что получается будет несколько классов с интерфейсом ISelectable на один DataManager на разные случаи.
Можно и так, но, но такая ситуация редка. Собственно сейчас ровно тоже самое, когда с ODS работаешь.
Вообще, поскольку за создание класса-обертки ты отвечаешь сам, то при создании можешь определить стратегию работы обертки с DataManager-ом, ну и реализовать одну обертку с несколькими стратегиями, если нужно.

S>Много кода получается. Неплохо было-бы совместить DataManager и интерфейсы в одном классе.
Ну совмести, хотя я бы наверное разнес, впрочем от ситуации зависит.... << RSDN@Home 1.2.0 alpha rev. 0>>

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

G>З.Ы. ODS — это такой экспресс-враппер, сделанный для того чтобы быстро клепать небольшие приложения и не испугать новичков интерфейсами и прочей фигней :)
Так-то оно так, но вот только в ODS есть часть функционала, который ручками реализуется муторно и некрасиво.... << RSDN@Home 1.2.0 alpha rev. 0>>

Здравствуйте, 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?... << RSDN@Home 1.2.0 alpha rev. 0>>

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

MC>Вобщемто я рад что у меня нет страха перед дизайнерами.
В восемдесят пятый раз объясняю. Дело не в дизайнере, а в том, что ODS работает с не типизированными строками, вместо объектов и возможности использовать его функционал типиировано — нет. Дизайнеру все фиолетово, он может генерить совершенно произвольный код, в любое место приложения, как напишешь.... << RSDN@Home 1.2.0 alpha rev. 0>>