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

A>Здравствуйте, minorlogic, Вы писали:
A>Так тебя забанят.

сглазил таки minorlogic

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

OE>сглазил таки minorlogic

Да от моего взгляда молоко сворачивается и мясо тухнет. А тут какой-то minorlogic

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

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

A>Так тебя забанят.

Да нет вроде ? правил не нарушаю.
Хочется больше конструктива почитать , ибо ветка для меня интересная.

Прошк прощения у автора , я только негатив вывалил. А про позитив забыл. Статья мне действительно очень понравилась , и поэтому вдвойне хотелось бы почитать больше конкретики. Думаю , что буду еще не раз к статью перечитывать.

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

M>Заметил странную особенность , ситаю посты adontz и все по делу , все понятно, простые примеры , решения.
Что там по делу, может я не разглядел? Где примеры и решения?

M>Читаю ваши посты , и кроме напыщенного опускания собеседника и раздувания щек мало что нахожу , странно , это мне только кажется ? ...

Какой вопрос, такой и ответ — чего же тут странного? Могу опустить и не напыщено, на щеки вроде не жалуюсь их раздутость меня вполне устраивает...
Если что-то не понятно — могу объяснить, мне не сложно, но только если вопрос задан не в виде пустых придирок.

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

M>Хочется больше конструктива почитать , ибо ветка для меня интересная.
Так задавайте конструктивные вопросы.

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

IB>Так задавайте конструктивные вопросы.

Возникли вопросы по применению схемы MVP к созданию пользовательских элементов управления.
Для примера можно взять обыкновенную кнопку. Если возможно, прокомментируйте мои следующие рассуждения и мысли.

Модель
-------
Поскольку кнопка может находиться в нескольких состояних State (normal, pressed, hottracked, disabled) необходимо где-то его сохранить. Пусть это будет модель.
Для возможности создания windowless контрола необходима также информация о местоположении кнопки Rect. Снова в модель.
С данными вроде разобрались.

  class ButtonModel
  ...
    // get
    Rect GetRect() const;
    State GetState() const;
    // set
    bool SetRect(Rect const&); // bool для уведомления о результете изменения  успех/неудача
    bool SetState(State);

View
-------
В случае с кнопкой интерфейс представления будет состоять из функций для отображения кнопки на экране, запроса на перерисовку кнопки и событий оповещающих Presenter о движении мыши и нажатиях на кнопки мыши (клавиатурные команды для простоты рассматривать не будем).
Получается так:

  class ButtonView
    ...
    // draw
    virtual void DrawButton(Rect const&, State) = 0;
    virtual void Invalidate(Rect const&) = 0;
    // ??? нужны ли
    virtual void CaptureMouse() = 0;
    virtual void ReleaseMouse() = 0;
    virtual bool IsMouseCaptured() = 0;

    DrawEvent OnDrawEvent;
    MouseMoveEvent OnMouseMoveEvent;
    LButtonDownEvent OnLButtonDownEvent;
    LButtonUpEvent OnLButtonUpEvent;

Тут у меня появляется небольшое недопонимание. Помимо вышеперечисленных функций Презентеру (поскольку он управляет логикой контрола) может понадобиться CaptureMouse и ReleaseMouse для корректного перехода из состояния в сотояние. К примеру юзер нажал на кнопку, но отпускать не спешит. Информация о движении мыши должна поступать в контрол даже если юзер при нажатой кнопке уведет мышь за пределы родительского окна. Достичь этого можно например захватив мышь. Выходит Презентер должен знать об особенностях конкретного представления, оконной библиотеки?

Presenter
---------

  class ButtonPresenter
  ...
    ButtonPresenter(Model*, View*);

    void OnDraw();
    void OnMouseMove(Point const&);
    bool OnLButtonDown(Point const&); // bool для уведомления о том, что сообщение обработано
    bool OnLButtonUp(Point const&);

// пример реализации одной из функций
bool ButtonPresenter::OnLButtonDown(Point const& pt)
{
  if(model->GetRect().IsPointInRect(pt))
  {
    view_->CaptureMouse();
    if(model_->SetState(State::Pressed))
    {
        view->Invalidate(model_.GetRect());
    }
    return true;
  }
  return false;
}

Реализации функций View у конкретного наследника тривиальна, приводить смысла не имеет. Здесь интересно другое. Если владелец кнопки захочет изменить ее местоположение или (пусть даже так) состояние, функциями какого класса он будет пользоваться? Не совсем правильно поставил вопрос. Конечно подобные функции есть только у модели. Но ведь у нее нет уведомлений представлению или презентеру об изменении. Что необходимо сделать? Добавить SetRect, SetState к Презентеру, Реализации вида или уведомления модели? Я немного запутался. Может в данном конкретном случае модель не нужна вовсе?

Также много вопросов возникает по взаимодействию триад MVP. Можете посоветовать конкретные примеры, в которых не сложно будет разобраться? Ну или сложно

PS. Большинство примеров что видел я, (например здесь) использую активную модель, более того именно модель (в одном из примеров — игра puzzle) является инициатором старта новых диалогов.

PPS. Прощу прощения за сумбурность изложения мыслей

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

А зачем вам понадобилось переписывать уже реализованные граф. примитивы?

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

R>А зачем вам понадобилось переписывать уже реализованные граф. примитивы?
Button использовался исключительно для примера.

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

GZ> bool SetRect(Rect const&); // bool для уведомления о результете изменения успех/неудача
GZ> bool SetState(State);
Какая может быть неудача и какая логика на этом может быть построена?

GZ>В случае с кнопкой интерфейс представления будет состоять из функций для отображения кнопки на экране, запроса на перерисовку кнопки и событий оповещающих Presenter о движении мыши и нажатиях на кнопки мыши (клавиатурные команды для простоты рассматривать не будем).
GZ>Получается так:
Не совсем. Обычно все-таки интерфейс View полее высокоуровневый, все эти отслеживания мыши и прочую конкретику берет на себя библиотека отображения. Интерфейс вью проще — нажали/не нажали, скрыли/показали, Enable/Disable, задали текст/изображение..

GZ>Тут у меня появляется небольшое недопонимание. Помимо вышеперечисленных функций Презентеру (поскольку он управляет логикой контрола) может понадобиться CaptureMouse и ReleaseMouse для корректного перехода из состояния в сотояние.
Нет, не понадобится, это забота View, так как все это конкретика определенного отображения на определенном устройстве.

GZ> Выходит Презентер должен знать об особенностях конкретного представления, оконной библиотеки?
Нет конечно.

GZ>// пример реализации одной из функций
Нет, призентер ничего не знает о конкретных кнопках мыши или клавиатуры. К нему просто приходит извещение о том, что состояние кнопки изменилось. Каким способом это произошло — его не интересует, это забота вью.
Забота презентера — изменить модель в соответствии с этим изменением и, возможно, изменить другие представления, то есть, довольно высокоуровневая логика.

GZ> Если владелец кнопки захочет изменить ее местоположение или (пусть даже так) состояние, функциями какого класса он будет пользоваться?
Все изменения модели происходят через соответствующий презентер.

GZ> Но ведь у нее нет уведомлений представлению или презентеру об изменении. Что необходимо сделать? Добавить SetRect, SetState к Презентеру, Реализации вида или уведомления модели?
Дело в том, что изменение модели, как правило, происходит не само по себе, а по причине того, что случилось какое-то внешние событие. Все внешние события проходят через презентер, соответственно соответствующий презентер знает о том, что модель поменялась. И обладая этим знанием может уведомить другие презентеры или View о том, что он что-то менял.
Это при условии, что мы хотим оставаться в рамках пассивной модели, однако ничто не запрещает реализовать и активную модель, если так удобнее.. Хотя на мой взгляд, лучше оставаться до самого последнего момента в рамках пассивной модели.

GZ>Также много вопросов возникает по взаимодействию триад MVP. Можете посоветовать конкретные примеры, в которых не сложно будет разобраться?
Ну, есть несколько ссылок в статье... В последнее время ничего по этой теме нового не попадалось.

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

ID>
Спасибо за ответ. Хочется разобраться c MVP

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

GZ>> bool SetRect(Rect const&); // bool для уведомления о результете изменения успех/неудача
GZ>> bool SetState(State);
IB>Какая может быть неудача и какая логика на этом может быть построена?
Вынести в модель логику проверку отличия переданного значения параметра от хранимого.
Наверно этим лучше заняться Presenter'y.


GZ>>В случае с кнопкой интерфейс представления будет состоять из функций для отображения кнопки на экране, запроса на перерисовку кнопки и событий оповещающих Presenter о движении мыши и нажатиях на кнопки мыши (клавиатурные команды для простоты рассматривать не будем).
GZ>>Получается так:
IB>Не совсем. Обычно все-таки интерфейс View полее высокоуровневый, все эти отслеживания мыши и прочую конкретику берет на себя библиотека отображения. Интерфейс вью проще — нажали/не нажали, скрыли/показали, Enable/Disable, задали текст/изображение..
В том то и дело, что отдельный элемент управления это не форма c данными пользователя. Отслеживание мыши и многое другое (фокус, клавиатура etc.) это дело контрола. Ибо больше некому. Модель — хранит данные, Presenter — управляет их изменением. Остается только представление.

GZ>>// пример реализации одной из функций
IB>Нет, призентер ничего не знает о конкретных кнопках мыши или клавиатуры. К нему просто приходит извещение о том, что состояние кнопки изменилось. Каким способом это произошло — его не интересует, это забота вью.
IB>Забота презентера — изменить модель в соответствии с этим изменением и, возможно, изменить другие представления, то есть, довольно высокоуровневая логика.

Тогда его интерфейс повторяет интерфейс модели + события от представления

class Presenter
...
    Rect GetRect() { return model->GetRect(); }
    State GetState() { return model->GetState(); }
    //
    void SetRect(Rect rect)
    {
      model->SetRect(rect);
      view->Draw(model->GetRect(), model->GetState());
    }
    void SetState(State state)
    {
      model->SetState(state);
      view->Draw(model->GetRect(), model->GetState());
    }
    // обработчики событий
    void OnSetRect() { SetRect(view->GetRect()); }
    void OnSetState() { SetState(view->GetState()); }

Очень напоминает активную модель в схеме MVC.

GZ>> Если владелец кнопки захочет изменить ее местоположение или (пусть даже так) состояние, функциями какого класса он будет пользоваться?
IB>Все изменения модели происходят через соответствующий презентер.
к примеру некоторая форма размещает кнопки на себе:

class OkCalcelForm
...
  void SetLayout()
    {
      GetOkButtonPresenter()->SetRect...;
        GetCancelButtonPresenter()->SetRect...;
    }

Я правильно понял?

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

GZ>Вынести в модель логику проверку отличия переданного значения параметра от хранимого.
А при чем здесь успех или неудача передачи данных во View?

GZ>В том то и дело, что отдельный элемент управления это не форма c данными пользователя. Отслеживание мыши и многое другое (фокус, клавиатура etc.) это дело контрола.
Нет, это все дело представления, презентеру должны более высокоуровневые события приходить, иначе он окажется привязан к конкретному способу взаимодействия с конкретным View и весь смысл шаблона потеряется.

GZ>Тогда его интерфейс повторяет интерфейс модели + события от представления
В простейших случаях так и есть.
Задача презентера — описать логику взаимодействия событий от вью и изменений модели. Если логика тривиальна, то и презентер получится этаким pass-thru объектом, который просто транслирует через себя вызовы и результаты.

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

IB>Задача презентера — описать логику взаимодействия событий от вью и изменений модели. Если логика тривиальна, то и презентер получится этаким pass-thru объектом, который просто транслирует через себя вызовы и результаты.
По-моему лучше все же взаимодействие представления и предъявителя построить по шаблону Command, частично повторяемость уйдет.

Здравствуйте, Иван Бодягин, Вы писали:

ИБ>Статья:
ИБ>Model-View-Controller в .Net

Автор(ы): Иван Бодягин
Дата: 25.07.2006
В наше время сложно найти разработчика, который не слышал бы о паттерне под названием Model-View-Controller или сокращенно MVC, что вообщем не удивительно, с задачей отделения данных от их представления сталкиваешься практически на каждом проекте. Однако, как ни странно, столь же сложно найти разработчика, который действительно четко себе представляет, что такое на самом деле паттерн MVC и как его можно реализовать в конкретной ситуации. Основная причина такой неоднозначности в том, что по историческим причинам данной аббревиатурой принято называть не один единственный паттерн, а целое семейство паттернов, призванное отделять представление от модели. Произошло это в силу разных обстоятельств. Отчасти из-за того что MVC не просто паттерн, а довольно объемное архитектурное решение, в котором каждый новый разработчик видел что-то свое и ставя во главу угла особенности своего проекта, реализовывал его по своему. Отчасти же из-за возраста данного паттерна, во времена его изобретения и сами приложения, и графические интерфейсы были существенно беднее чем в наше время, с тех пор они сильно эволюционировали и вместе с ними изменялся и сам паттерн. Данная статья посвящена также одному из паттернов входящих в это семейство, причинам его появления, особенностям применения, преимуществам и недостаткам, а так же описанию сопутствующих паттернов.

В статье для оповещения Presenter-a об изменениях во View используется событие:

   public interface IView
   {
      /// <summary>
      /// Событие ввода значения по цельсию
      /// </summary>
      event EventHandler<EventArgs> SetCelsius;
   }

и в реализации View:

      /// <summary>
      /// Обработка событий тоже примитивна, они просто пробрасываются
      /// в соответствующие события Presenter-а
      /// </summary>
      private void _celsiusButton_Click(object sender, EventArgs e)
      {
         if (SetCelsius != null)
            SetCelsius(this, EventArgs.Empty);
      }

Presenter подписывается на это событие и обрабатывает его должным образом.

У меня возник очень серьезный спор по поводу использования событий для обработки изменеий во View. Альтернатвным решением коллеги предлагают иметь во View ссылку на Presenter, а в Presenter-е объявить

public void SetCelsius();

а View изменить следующим способом:

      private void _celsiusButton_Click(object sender, EventArgs e)
      {
            _presenter.SetCelsius();
      }

Покопавшись в сети, я нашел несколько статей, объясняющих, почему прямые вызовы могут быть лучше, чем события (например, здесь).

В кратце — легче читать и отлаживать код, легче юнит-тестирование.

В связи с этим вопрос — какие преимущества использования событий для вызова кода Presenter-а из View и когда какой подход выбирать?

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

Z>В связи с этим вопрос — какие преимущества использования событий для вызова кода Presenter-а из View и когда какой подход выбирать?
Лично я преимуществ не вижу, может просто не понял. По-моему, автор сделал так, чтобы несколько предъявителей могли работать с одним представлением. У меня иной подход — несколько представлений могут работать с одним предъявителем. Тот же Проводник Windows в пример: модель-предъявитель каталога — 1 шт., представления каталога в дереве каталогов и в окне просмотра содержимого каталога — 2 шт. Единственное но, при таком подходе общение представления и предъявителя лучше строить по шаблону Command, а не так как вы процитировали.

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

Z>В связи с этим вопрос — какие преимущества использования событий для вызова кода Presenter-а из View и когда какой подход выбирать?
Там прямо в приведенной тобой статье сказано

Making the View to Presenter communication work through events has the indisputable advantage of maximizing loose coupling

Мне кажется сомнительным, что знание вью о презентере облегчит юнит-тестирование, скорее наоборот.
View меняется гораздо чаще чем презентер и одна из основных целей MVC/MVP — обеспечить легкость этой замены, а прибиванием вью гвоздями к конкретному презентеру подобная замена серьезно усложняется. Именно поэтому Даже в классическом паттерне именно View обладает well known интерфейсом и связь всегданаправлена олько в одну сторону.

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

У меня большая просьба автору.
Не могли бы Вы привести пример более сложного чем в статье Presenter'а, логику которого необходимо было бы тестировать.

Спасибо

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

А>Не могли бы Вы привести пример более сложного чем в статье Presenter'а, логику которого необходимо было бы тестировать.
В презентере содержится верхний уровень того, что обычно понимается под бизнес-логикой, вот ее и надо тестировать.
Например, при нажатии на кнопку "оформить заказ" надо сохранить корзину в базе, запросить данные о кредитке, поместить в очередь сообщение для менеджера, поместить в очередь мэйл для клиента и сделать еще кучу всякой фигни, возможно даже в рамках транзакции..
Все это размещается в презентере в обработчике соответствующего события, протестировать это не повредит...

Здравствуйте, Иван,

Разобрался в чем у меня проблема, связанная c пониманием MVC (MVP). Я путаю данные модели с данными конкретного view, при проектировании пользовательских элементов управления.
Взять к примеру splitter, разделяющий два окна. Его положение — это данные модели? Или специфика конкретного view? А позиция бегунка в slider'e? А название кнопки?
Более того, с данными конкретного view тоже может быть (и будет) связана определенная логика, которую тоже неплохо было бы протестировать. Еще раз модель и презентер?
Или нет?

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

GZ>Еще раз модель и презентер?
GZ>Или нет?
Up 2 You...
Зависит от сложности проекта и степени переиспользуемости которой хочется добиться.. Если пишется UI Framework, то разумно все, самые примитивные контролы разбить на триады MVP и тестировать по отдельности, затем тоже самое с более общими контролами, ect... Если же это единичный проект, то проще оставить все это на откуп View.

Ну и в чём прикол? Любая попытка реализовать MVC с описанным инструментарием приведёт к описанному архитектурному решению. Собственно говоря, врятли кто то захочет реализовывать названную автором "типичную схему" (хотя что в ней типичного )
типичная схема взаимодействия компонентов паттерна выглядит примерно так: Контроллер перехватывает событие извне и в соответствии с заложенной в него логикой, реагирует на это событие изменяя Mодель, посредством вызова соответствующего метода Модели. После изменения Модель бросает событие о том что она изменилась, и все подписанные на это события Представления, получив его, обращаются к Модели за обновленными данными, после чего их и отображают.