Как использовать подобный шаблон с виртуальным гридом?
У грида существует событие, которым он запрашивает данные для отдельной ячейки (т.е. в обработчик события передаётся объект, одно из свойств которого является значением, которое будет присвоено ячейке). View здесь — это форма, на которой находится грид. Как правильнее реализовать View и Presenter для данного случая?

Здравствуйте, <Аноним>, Вы писали:

А>У грида существует событие, которым он запрашивает данные для отдельной ячейки (т.е. в обработчик события передаётся объект, одно из свойств которого является значением, которое будет присвоено ячейке). View здесь — это форма, на которой находится грид. Как правильнее реализовать View и Presenter для данного случая?
View выбрасывает событие о том, что ему нужна следующая порция данных. Перехватив это событие презентер лезет в модель, забирает данные и подпихивает их во View через зарание проделанное отверстие (aka метод интерфейса)

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

IB>Здравствуйте, <Аноним>, Вы писали:

А>>У грида существует событие, которым он запрашивает данные для отдельной ячейки (т.е. в обработчик события передаётся объект, одно из свойств которого является значением, которое будет присвоено ячейке). View здесь — это форма, на которой находится грид. Как правильнее реализовать View и Presenter для данного случая?
IB>View выбрасывает событие о том, что ему нужна следующая порция данных. Перехватив это событие презентер лезет в модель, забирает данные и подпихивает их во View через зарание проделанное отверстие (aka метод интерфейса)

В этом случае мне придётся сохранять в поле (field) формы объект, передаваемый в событие грида, чтобы этот метод интерфейса IView мог его поменять.
Это нормально?

А если, допустим, объявить в интерфейсе IView событие с сигнатурой (object sender, IItemInfo info), где IItemInfo — интерфейс.
interface IItemInfo
{
object Value {get;set;}
}
В presenter подписываться на это событие и в обработчике задавать info.Value
А в форме (View) поднимать это событие, передавая в качестве info объект класса, реализующего интерфейс IItemInfo и переадресующего свойство Value объекту события грида.
Правда, в этом простейшем случае нарушается рекомендация по созданию событий (второй аргумент делегата события не наследуется от EventArgs. Впрочем, можно ввести абстрактный класс, наследующий от EventArgs и IItemInfo. А во View для поднятия события использовать уже наследник этого абстрактного класса.
Это, конечно, сложнее, чем предложенный Вами вариант. К тому же, не нарушает ли это идею данного шаблона?

Что посоветуете?

Здравствуйте, Аноним, Вы писали:

А>А если, допустим, объявить в интерфейсе IView событие с сигнатурой (object sender, IItemInfo info), где IItemInfo — интерфейс.
А>interface IItemInfo
А>{
А> object Value {get;set;}
А>}
А>В presenter подписываться на это событие и в обработчике задавать info.Value
А>А в форме (View) поднимать это событие, передавая в качестве info объект класса, реализующего интерфейс IItemInfo и переадресующего свойство Value объекту события грида.
А>Правда, в этом простейшем случае нарушается рекомендация по созданию событий (второй аргумент делегата события не наследуется от EventArgs. Впрочем, можно ввести абстрактный класс, наследующий от EventArgs и IItemInfo. А во View для поднятия события использовать уже наследник этого абстрактного класса.
А>Это, конечно, сложнее, чем предложенный Вами вариант. К тому же, не нарушает ли это идею данного шаблона?

А>Что посоветуете?

Насчет дата-ориентированных EventArgs: напишите генерик и не имейте проблем:

public class EventArgs<TArgs> : EventArgs
{
private TArgs arg;
public EventArgs(TArg arg)
{
this.arg = arg;
}
public TArgs Arg
{
get
{
return this.arg;
}
}
}

Насчет MVP: учитывая, что речь идёт о платформе .NET, я рекомендую следующую схему:
Данные для грида организовать в коллекцию классов. А сам класс коллекция — источник данных для грида.

презентер занимается двумя вещами
1. Задает представлению объект-источник данных (в вашем случае — коллекцию). И, если это не .NET, занимается связыванием источника данных с контролами представления.
2. Обновляет источник данных.

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

Здравствуйте, StanislavB, Вы писали:
SB>Насчет дата-ориентированных EventArgs: напишите генерик и не имейте проблем:


SB>

SB>public class EventArgs<TArgs> : EventArgs
SB>{
SB>private TArgs arg;
SB>public EventArgs(TArg arg)
SB>{
SB>this.arg = arg;
SB>}
SB>public TArgs Arg
SB>{
SB>get
SB>{
SB>return this.arg;
SB>}
SB>}
SB>}

SB>

Если под TArgs Вы имели в виду тип агргумента события грида, то в этом случае получается зависимость Presenter от конкретной реализации IView (от типа аргумента события грида). Если же другой тип, то я не понимаю, в чём преимущество generic в этом случае?

Может быть поможет быть ...
http://rsdn.ru/forum/message/2566219.1.aspx

Автор: Stormblast
Дата: 30.06.07

Здравствуйте, Аноним, Вы писали:

А>Если под TArgs Вы имели в виду тип агргумента события грида, то в этом случае получается зависимость Presenter от конкретной реализации IView (от типа аргумента события грида). Если же другой тип, то я не понимаю, в чём преимущество generic в этом случае?

Например так:
public event EventHandler<EventArgs<IItemInfo>> GetItemInfo;

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

SB>Например так:
SB>public event EventHandler<EventArgs<IItemInfo>> GetItemInfo;

Понял. А всё-таки, какой вариант из двух перечисленных более отвечает идее MVP?
1. Передавать readonly аргументы в событие, а потом из presenter вызывать метод-мутатор IView, передавая ему результат вычислений на основе readonly-аргументов.
2. Передовать readonly и writeable аргументы в событие, на основе readonly вычислять значение и возвращать его в IView через writeable аргумент события.

Здравствуйте, <Аноним>, Вы писали:

А>В этом случае мне придётся сохранять в поле (field) формы объект, передаваемый в событие грида, чтобы этот метод интерфейса IView мог его поменять.
А>Это нормально?
Я имел ввиду следующее...

interface IView 
{
    Event RequireNewData(/*здесь может быть информация о том какие именно данные нужны, но как правило обходится без этого*/) // событие на которое подписан презентер
    void SetNewData(Item item)                  // Дырка через которую презентер подпихивает новые данные.
}

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

IB>Я имел ввиду следующее...
IB>

IB>interface IView 
IB>{
IB>    Event RequireNewData(/*здесь может быть информация о том какие именно данные нужны, но как правило обходится без этого*/) // событие на которое подписан презентер
IB>    void SetNewData(Item item)                  // Дырка через которую презентер подпихивает новые данные.
IB>}
IB>

Это я понял.
Просто имеющийся виртуальный грид ведь построчно (даже поячеечно требует данные), при этом данные ему нужно подпихивать в аргумент события. При использовании приведённого здесь Вами подхода этот аргумент нужно будет сохранять во view, чтобы в SetNewData изменить его. А в RequireNewData нужно передавать информацию о строке и колонке ячейки, данные для которой требуются.

Заодно хотелось бы услышать от Вас комментарии по следующему вопросу: должен ли view явно вызывать методы presenter или лучше использовать для этого события?
В Вашей статье используется второй подход. В MSDN Magazine — первый.
Хотя, возможно, вопрос нужно ставить шире — должен ли view знать что-либо о presenter?

Здравствуйте, <Аноним>, Вы писали:

А>Просто имеющийся виртуальный грид ведь построчно (даже поячеечно требует данные), при этом данные ему нужно подпихивать в аргумент события. При использовании приведённого здесь Вами подхода этот аргумент нужно будет сохранять во view, чтобы в SetNewData изменить его. А в RequireNewData нужно передавать информацию о строке и колонке ячейки, данные для которой требуются.
Если нужно использовать стандартный виртуальный грид, то есть несколько вариантов. Во-первых, можно в презентере абстрагироваться от колонок и ячеек и передавать данные во вью более крупными порциями, по строкам, например (презентер ничего не должен знать об особенностях реализации грида, а колонки и ячейки — это именно особенности). Таким образом, во вью образуется локальный кеш данных и логика обновления грида из этого кеша останется целиком во вью. Получается этакая двойная виртуализация, что по идее должно сказаться положительно на производительности, но логика получается не оченьтривиальной. Второй вариант — поступить в лоб, раз грид нам навязывает именно такую схему взаимодействия, просто пробрасывать это событие в презентер и обновлять из презентера конкретную ячейку, это проще, но идеологически не совсем верно...

А>Хотя, возможно, вопрос нужно ставить шире — должен ли view знать что-либо о presenter?
Нет, не должен. View может скорее знать что-то о модели, если мы имеем дело с активным вью, но о презентере он знать не должен. Во-первых подобное знание практически наверняка привяжет вью к конкретному презентеру. Во-вторых, код гораздо проще и понятнее, да и логика прозрачнее, когда все связи направлены в одну сторону. Ну и наконец, в-третих, с идеологической точки зрения, вся бизнес-логика сосредоточена в презентере, именно он является источником изменений в бизнес-объектах, а если мы дадим View ркоятку, за которую он может дергать презентер, то часть логики переедет во вью и она размажется по двум классам. Посмотри на классическую схему MVC, там Controller знает о вью, но ни как не наоборот, обратная связь только через события.