Решился на днях попробовать задействовать юнит тесты в приложении на винформах с тестированием логики представления данных. Всегда подозревал что затея это сомнительная, но всё-таки переборол внутренний протест и заставил сделать это. Задействовал для ентого дела ныне модный супер паттерн MVP . Сухой остаток на текущий момент — вместо одного класса формы с обработчиками в стиле

   void SomeEventHandler(object sender, EventArgs e) 
   {
         int val = _serverApi.GetCurrentSignalLevel();
         _txtSignalValue.Text = val.ToString();
   }

Получаем

   class MyForm : IView 
   {
     void SomeEventHandler(object sender, EventArgs e) 
     {
          FireSignalRefresh();
     }

     void SetSignalValue(int val)  
     {
         _txtSignalValue.Text = val.ToString();
     }
   }

   class MyPresenter 
   {
     void SignalRefresh() {
        _view.SetSignalValue(_serverApi.GetCurrentSignalLevel());
     } 
   }

По моему достаточный геморрой и много лишнего кода, делающего общую логику туманной и менее прозрачной. Если теперь предположить, что таких обработчиков и методов в интерфейсе IView будет дофига, то количество лишней работы становится колосальным. Для тестировавания делаем мок на IView и дёргаем методы презентера. однако при сложной отображалке этот процесс становится довольно проблематичным... Если у кого есть хорошие ссылки по ентому процессу накидайте пожалуйста. А то кроме довольно малоинформативных статеек с codeproject под руку не попадается ничего. Везде приводят простенький пример, хотя даже на простом примере видно какой это геморрой и сколько лишнего времени уходит на написание презентеров, реализаций интерфейсов IView, пересылки сообщений в презентер...

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

1. Во-первых, не обязательно использовать события. Можно использовать обсервер.
Тогда код будет несколько более внятный. Но это, конечно, палка о двух концах

2. Одна из целей MVP — борьба со сложностью, которая проявляется в более-менее больших проектах. Из-за этого постоянно возникает проблема с примерами. Простой пример позволяет наглядно продемонстрировать принцип, но ставит некоторых в тупик: а нахрена столько лишнего кода, когда все можно сделать значительно проще. С другой стороны, сложный и потому приближенный к реальности пример способен продемонстрировать положительный эффект от MVP, но труден в написании и сильно теряет в наглядности.

A>По моему достаточный геморрой и много лишнего кода, делающего общую логику туманной и менее прозрачной. Если теперь предположить, что таких обработчиков и методов в интерфейсе IView будет дофига, то количество лишней работы становится колосальным.

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

A>Для тестировавания делаем мок на IView и дёргаем методы презентера. однако при сложной отображалке этот процесс становится довольно проблематичным...

4. По поводу "сложных отображалок". Пример, который ты привел, — это так называемый Passive View, когда view фактически состоит из геттеров и сеттеров для простых типов. Этот вариант, конечно, оптимален с точки зрения тестирования, но в случае сложных контролов он не всегда удобен. В таком случае стоит посмотреть в сторону Supervising Controller. Здесь view отводится более активная роль в триаде MVP.

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

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

MVK>1. Во-первых, не обязательно использовать события. Можно использовать обсервер.
MVK>Тогда код будет несколько более внятный. Но это, конечно, палка о двух концах

MVK>2. Одна из целей MVP — борьба со сложностью, которая проявляется в более-менее больших проектах. Из-за этого постоянно возникает проблема с примерами. Простой пример позволяет наглядно продемонстрировать принцип, но ставит некоторых в тупик: а нахрена столько лишнего кода, когда все можно сделать значительно проще. С другой стороны, сложный и потому приближенный к реальности пример способен продемонстрировать положительный эффект от MVP, но труден в написании и сильно теряет в наглядности.

Было б очень любопытно посмотреть как используется MVP а рабочем проекте, примерам я не очень доверяю .

A>>По моему достаточный геморрой и много лишнего кода, делающего общую логику туманной и менее прозрачной. Если теперь предположить, что таких обработчиков и методов в интерфейсе IView будет дофига, то количество лишней работы становится колосальным.

MVK>3. Если методов в IView будет дофига, то просто напрашивается декомпозиция IView на несколько интерфейсов. Если контрол достаточно сложный, то между ним и презентером можно ввести Adapter(я так поступаю в случае с гридом, например). Adapter, в таком случае, будет реализовывать интерфейс IView.

Не поделитесь кодом как это всё выглядит в рабочем проекте? Если есть юнит тесты этого хозяйства то вдвойне любопытно .

A>>Для тестировавания делаем мок на IView и дёргаем методы презентера. однако при сложной отображалке этот процесс становится довольно проблематичным...

MVK>4. По поводу "сложных отображалок". Пример, который ты привел, — это так называемый Passive View, когда view фактически состоит из геттеров и сеттеров для простых типов. Этот вариант, конечно, оптимален с точки зрения тестирования, но в случае сложных контролов он не всегда удобен. В таком случае стоит посмотреть в сторону Supervising Controller. Здесь view отводится более активная роль в триаде MVP.

Ща посмотрим

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

A>Было б очень любопытно посмотреть как используется MVP а рабочем проекте, примерам я не очень доверяю .
Насколько понял по примеру, вы пошли по пути описанному IB в статье "Model-View-Controller в .NET". Есть и альтернативные решения... точнее отличающиеся ньюансами реализации. К примеру, такой. Все сказанное воспринимать в стиле можно так, не говорю, что это обязательно только так и "нужно.

1. Плюсом к сказанному выше MaximVK: если активно использовать обобщения (generics) по всевозможным сущностям, то тестирование компонентов предъявителя-представления не будет зависеть от того, с какими моделями работает предъявитель или насколько сложный отображатель использует представление: метку, кнопку, таблицу, дерево и прочее — всем этим можно параметризовать представление и использовать в тестах их заглушки (вроде mock). Кроме того, в определенных приложениях можно замахнуться и на большее — параметризовать и предъявитель, и представление моделью (это описывано в другой статье про MVC).
   
2. С одной стороны, предъявитель и представление могут работать по Observer: Presenter — Publisher, View — Subscriber — к одному предъявителю могут подключиться множество представлений, которые он оповещает после изменения модели. В принципе, практически тоже самое, что и в классическом MVC с активной моделью, только здесь, в MVP, модель пассивная, максимально независима от остальных компонентов триады, а вся тяжеловесная логика взаимодействия зашита в предъявителе.
   
3. С другой стороны, в другом направлении они могут общаться по Command: View — Initiator, Presenter — Client, Model — Recipient. Представление формирует команду, шлет ее в запросе, предъявитель распаковывает команду, устанавливает команде получателя (команда узнает модель, над которой нужно выполнить свои действия), запускает ее (логику конкретных измненений инкапсулирует команда), запрашивает у команды после выполнения команду, которая может отменить ее действия, пополняет ею список отмен (поддержка Undo, аналогично для Redo).

A>Не поделитесь кодом как это всё выглядит в рабочем проекте? Если есть юнит тесты этого хозяйства то вдвойне любопытно .
Примеры тестов поэтому тривиальны (никакой конкретики, никакого GUI, только тестирование каркаса), что-то вроде такого (от руки да на память):

package ru.rsdn.mvp.test;

import org.junit.Test;
import org.junit.Assert;

import ru.rsdn.mvp.Model;
import ru.rsdn.mvp.Presenter;
import ru.rsdn.mvp.View;

/**
 * Одновременно и представление и тест работы
 * одного представления с одним предъявителем
 */
public class ViewTest extends View<SomeBLLObject> {
    private int counter;
    
    @Test
    public void test() {
        // формируем модель
        final Model<SomeBLLObject> model = new Model<SomeBLLObject>(new SomeBLLObject());
        // назначаем ей предъвителя
        final Presenter<SomeBLLObject> presenter = new Presenter<SomeBLLObject>(model);
        // прицепляем представление к предъявителю
        setPresenter(presenter);
        // полетели тестировать...
        edit(new SomeBLLObject(new SomeParameter()));
        Assert.assertEquals(counter, 1); // регистрируем получение уведомления
        undo();
        Assert.assertEquals(counter, 2);
        // и т.п. проверки
    }

    @Override
    public void changed(Model<SomeBLLObject> model) {
        counter++; // счетчик событий об изменении модели
        // ...
        // можно также поставить проверки корректности изменения
    }
}

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

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

A>>Было б очень любопытно посмотреть как используется MVP а рабочем проекте, примерам я не очень доверяю .
R>Насколько понял по примеру, вы пошли по пути описанному IB в статье "Model-View-Controller в .NET". Есть и альтернативные решения... точнее отличающиеся ньюансами реализации. К примеру, такой. Все сказанное воспринимать в стиле можно так, не говорю, что это обязательно только так и "нужно.
Я пошёл по тому пути который мне показался наиболее простым и прямым. Организовывать ли общение через события или через интерфейс для меня не принципиально и суть проблемы не в этом. Сразу спрошу, что вы конкретно использовали? Дело в том, что то как, это можно организовать, я вобщем и цлом вполне могу представить, интересует как это используют на практике. Первое моё ощущение — много лишней работы, геморрно писать юнит тесты при сомнительных плюсах . поэтому хотелось бы понять в чём моя ошибка.

R>

1. Плюсом к сказанному выше MaximVK: если активно использовать обобщения (generics) по всевозможным сущностям, то тестирование компонентов предъявителя-представления не будет зависеть от того, с какими моделями работает предъявитель или насколько сложный отображатель использует представление: метку, кнопку, таблицу, дерево и прочее — всем этим можно параметризовать представление и использовать в тестах их заглушки (вроде mock). Кроме того, в определенных приложениях можно замахнуться и на большее — параметризовать и предъявитель, и представление моделью (это описывано в другой статье про MVC).
   Параметризовать можно всё, но насколько это будт юзабельно и не офигеешь ли писать такие юнит тесты . Примерчик не кинете?
   
   R>
2. С одной стороны, предъявитель и представление могут работать по Observer: Presenter — Publisher, View — Subscriber — к одному предъявителю могут подключиться множество представлений, которые он оповещает после изменения модели. В принципе, практически тоже самое, что и в классическом MVC с активной моделью, только здесь, в MVP, модель пассивная, максимально независима от остальных компонентов триады, а вся тяжеловесная логика взаимодействия зашита в предъявителе.
   В каждой второй статье по MVC/MVP пишут, как просто будет менять отип View без смены контроллера. Но проблема в том, что в 99% случаев и не потребуется этого делать, ровно как и не потребуется аттачить кучу вьюшек к одному контроллеру.
   
   R>
3. С другой стороны, в другом направлении они могут общаться по Command: View — Initiator, Presenter — Client, Model — Recipient. Представление формирует команду, шлет ее в запросе, предъявитель распаковывает команду, устанавливает команде получателя (команда узнает модель, над которой нужно выполнить свои действия), запускает ее (логику конкретных измненений инкапсулирует команда), запрашивает у команды после выполнения команду, которая может отменить ее действия, пополняет ею список отмен (поддержка Undo, аналогично для Redo).

Вы представляете скольок это будет стоить? Вместо того, что бы в обработчике клика по кнопке вызвать _txtSignalValue.Text = 10, надо отфорвордить вызов в контроллер, в контроллере сформировать команду, отправить её во View, который её распакует и сделает действие запрошенно. И так на каждый чих в каждой форме.

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

A>Я пошёл по тому пути который мне показался наиболее простым и прямым. Организовывать ли общение через события или через интерфейс для меня не принципиально и суть проблемы не в этом. Сразу спрошу, что вы конкретно использовали? Дело в том, что то как, это можно организовать, я вобщем и цлом вполне могу представить, интересует как это используют на практике. Первое моё ощущение — много лишней работы, геморрно писать юнит тесты при сомнительных плюсах . поэтому хотелось бы понять в чём моя ошибка.
Конкретики, если речь про используемую графическую библиотеку или HTML-рендеринг, никакой и нет. Это ж просто каркас, подцепляй его куда угодно. Задача в том, чтобы исключить логически ошибки в самом каркасе — затем и тесты.

A>Параметризовать можно всё, но насколько это будт юзабельно и не офигеешь ли писать такие юнит тесты . Примерчик не кинете?
Писать тесты для каждого BLL-объекта и не нужно, при параметризации достаточно и одного теста: он ведь только контролирует корректность работы MVP — что при определенной команде от представления, предъявитель выполнил соответствующие действия, а модель изменила значение на нужное — о чем узнало представление. Пример? А чем приведенный выше не устраивает?

A>В каждой второй статье по MVC/MVP пишут, как просто будет менять отип View без смены контроллера. Но проблема в том, что в 99% случаев и не потребуется этого делать, ровно как и не потребуется аттачить кучу вьюшек к одному контроллеру.
Не знаю, как у вас, но у меня такая проблема была и есть.
Проводник Windows помните? В нем два представления: одно отображает каталоги/файлы файловой системы (ФС) в виде дерева, другое тоже самое в виде списка содержимого каталогов — вообще говоря, здесь модель-предъявитель в одном лице. Вы предлагаете каждой формочке делать по собственному контрллеру, каждый из которых будет делать отдельный запрос к ФС? Представьте, насколько долго окно такой программы будет "беленьким окошком" (если, конечно, приложение не особо зашивается на реактивность интерфейса), если пользователь в дереве тыркнет на "C:", в котором несколько тысяч каталогов/файлов.

A>Вы представляете скольок это будет стоить? Вместо того, что бы в обработчике клика по кнопке вызвать _txtSignalValue.Text = 10, надо отфорвордить вызов в контроллер, в контроллере сформировать команду, отправить её во View, который её распакует и сделает действие запрошенно. И так на каждый чих в каждой форме.
Гм... странно, а зачем вы вообще взялись за MVC/MVP, если все еще убеждены, что зашивание логики в форму (то есть никакого контроллера, и собственно представления как такового — нет) проще?

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

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

R>Конкретики, если речь про используемую графическую библиотеку или HTML-рендеринг, никакой и нет. Это ж просто каркас, подцепляй его куда угодно. Задача в том, чтобы исключить логически ошибки в самом каркасе — затем и тесты.
Какой каркас, кого куда цеплять?

A>>Параметризовать можно всё, но насколько это будт юзабельно и не офигеешь ли писать такие юнит тесты . Примерчик не кинете?
R>Писать тесты для каждого BLL-объекта и не нужно, при параметризации достаточно и одного теста: он ведь только контролирует корректность работы MVP — что при определенной команде от представления, предъявитель выполнил соответствующие действия, а модель изменила значение на нужное — о чем узнало представление. Пример? А чем приведенный выше не устраивает?
Тем, что модель — это не один объект. Контроллер (презентер, или ещё как там его обозвать) не привязан к одному бизнес объекту, он общается с доменной моделью, ну возможно с частью модели.

A>>В каждой второй статье по MVC/MVP пишут, как просто будет менять отип View без смены контроллера. Но проблема в том, что в 99% случаев и не потребуется этого делать, ровно как и не потребуется аттачить кучу вьюшек к одному контроллеру.
R>Не знаю, как у вас, но у меня такая проблема была и есть.
А в каких задачах у вас такая необходимость постоянно возникает если не секрет?
R>Проводник Windows помните? В нем два представления: одно отображает каталоги/файлы файловой системы (ФС) в виде дерева, другое тоже самое в виде списка содержимого каталогов — вообще говоря, здесь модель-предъявитель в одном лице. Вы предлагаете каждой формочке делать по собственному контрллеру, каждый из которых будет делать отдельный запрос к ФС? Представьте, насколько долго окно такой программы будет "беленьким окошком" (если, конечно, приложение не особо зашивается на реактивность интерфейса), если пользователь в дереве тыркнет на "C:", в котором несколько тысяч каталогов/файлов.
Это совершенно конкретная задача, где это нужно, а в большинстве остальных не нужно. Ну в оольшинстве десктопных приложений не нужно каждую форму в зависимости от ситуации по разному рисовать.

A>>Вы представляете скольок это будет стоить? Вместо того, что бы в обработчике клика по кнопке вызвать _txtSignalValue.Text = 10, надо отфорвордить вызов в контроллер, в контроллере сформировать команду, отправить её во View, который её распакует и сделает действие запрошенно. И так на каждый чих в каждой форме.
R>Гм... странно, а зачем вы вообще взялись за MVC/MVP, если все еще убеждены, что зашивание логики в форму (то есть никакого контроллера, и собственно представления как такового — нет) проще?

Затем, что код формы фигово тестировать. Затем, что по любому практически все задачи форма форвордит различным службам, при использовании контроллера это вроде как систематизируется. А как вы сказали делать команды — так если у вас с полтинник хотя бы форм, каждая форма кидает с пятнашку событий контроллеру, представляете скока у вас будет комманд?

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

A>Какой каркас, кого куда цеплять?
См. примеры к статье "Обобщенный MVC", там показно использование MVC-каркаса настольном приложении на Java SWT (а мог бы быть спокойно и Swing) и в веб-приложении C# ASP.NET.

A>Тем, что модель — это не один объект. Контроллер (презентер, или ещё как там его обозвать) не привязан к одному бизнес объекту, он общается с доменной моделью, ну возможно с частью модели.
И что? Честно говоря, не понял суть претензии.

A>А в каких задачах у вас такая необходимость постоянно возникает если не секрет?
Да в любых. Ну самое простое: компания, сотрудник. Вначале пользователь заполняет словарь компаний (представление №1), потом словарь сотрудников, который, к примеру, отображается в виде таблицы, которая для выбора компании, в которой работает сотрудник, использует редактор ячейки в виде выпадающего списка компаний. Вот этот редактор и является тем представлением №2, который также цепляется к предъвителю компаний. Как только изменится модели списка компаний — обновятся все заинтересованные в нем представления.



А вообще говоря, словари, бывают, используются во множестве форм, так что... Лень было компоновать, чтобы все влезло на снимок, но можно было бы показать, что словарь компаний используется еше в 3 формах.

A>Это совершенно конкретная задача, где это нужно, а в большинстве остальных не нужно. Ну в оольшинстве десктопных приложений не нужно каждую форму в зависимости от ситуации по разному рисовать.
Чую, "большинство десктопных приложений" писано вами...

A>Затем, что код формы фигово тестировать. Затем, что по любому практически все задачи форма форвордит различным службам, при использовании контроллера это вроде как систематизируется. А как вы сказали делать команды — так если у вас с полтинник хотя бы форм, каждая форма кидает с пятнашку событий контроллеру, представляете скока у вас будет комманд?
Во-первых, формы здесь ни при чем, они и представления не имеют о командах, команды шлет представление: форма != представление, форма может наследовать, инкапсулировать и т.п. представление. Во-вторых, представляю: в большинстве случаев мне хватает AddCommand (добавить элемент в список), RemoveCommand (удалить элемент из списка), EditCommand (изменить элемент). В-третьих, какая разница, сколько требуется в конкретном случае специфических команд при использовании шаблона Command? Предъявитель может принять любую команду — реализацию интерфейса ICommand.

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

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

A>>Какой каркас, кого куда цеплять?
R>См. примеры к статье "Обобщенный MVC", там показно использование MVC-каркаса настольном приложении на Java SWT (а мог бы быть спокойно и Swing) и в веб-приложении C# ASP.NET.

A>>Тем, что модель — это не один объект. Контроллер (презентер, или ещё как там его обозвать) не привязан к одному бизнес объекту, он общается с доменной моделью, ну возможно с частью модели.
R>И что? Честно говоря, не понял суть претензии.

A>>А в каких задачах у вас такая необходимость постоянно возникает если не секрет?
R>Да в любых. Ну самое простое: компания, сотрудник. Вначале пользователь заполняет словарь компаний (представление №1), потом словарь сотрудников, который, к примеру, отображается в виде таблицы, которая для выбора компании, в которой работает сотрудник, использует редактор ячейки в виде выпадающего списка компаний. Вот этот редактор и является тем представлением №2, который также цепляется к предъвителю компаний. Как только изменится модели списка компаний — обновятся все заинтересованные в нем представления.
Представленный пример не является ярким примером MVC. Основной задачей является обновление представлений при изменении модели, а не удаление бизнес логики от GUI. К примеру, ничего не мешает сделать некоторый объект, кидающий событие при изменении списка компаний. Все заинтересованные в этом событие объекты ( совершенно не обязательно это вообще будет представлением) получат извещение и произведут соответсвующие действия.


A>>Затем, что код формы фигово тестировать. Затем, что по любому практически все задачи форма форвордит различным службам, при использовании контроллера это вроде как систематизируется. А как вы сказали делать команды — так если у вас с полтинник хотя бы форм, каждая форма кидает с пятнашку событий контроллеру, представляете скока у вас будет комманд?
R>Во-первых, формы здесь ни при чем, они и представления не имеют о командах, команды шлет представление:
Очень даже причём. Вы спросили нафига вам MVP, я ответил .

R> форма != представление, форма может наследовать, инкапсулировать и т.п. представление.
Кто б спорил .

R> Во-вторых, представляю: в большинстве случаев мне хватает AddCommand (добавить элемент в список), RemoveCommand (удалить элемент из списка), EditCommand (изменить элемент). В-третьих, какая разница, сколько требуется в конкретном случае специфических команд при использовании шаблона Command? Предъявитель может принять любую команду — реализацию интерфейса ICommand.
Это так, если все формы оимеют схожную структуру. А если в одной форме показывается список сотрудников, в другой выводится статискика по клиентам, в третьей управление сервером, то у вас будет куча команд. Охота вам их писать? даже если охота врятли их наличие сделает код приложения более ясным и понятным.

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

A>Представленный пример не является ярким примером MVC.
Ну какой уж есть.

A>Основной задачей является обновление представлений при изменении модели, а не удаление бизнес логики от GUI.
И то, и другое в равной степени.

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

A>Очень даже причём. Вы спросили нафига вам MVP, я ответил .
А я, честно говоря, все еще не понимаю "нафига вам MVP".

A>Это так, если все формы оимеют схожную структуру.
Да не формы... представления!
Ну что можно еще сделать, чтобы ициниировать событие об изменении коллекции некоторых элементов, как не добавить, удалить, отредактировать элемент коллекции? Просто, к качестве примера, действия Undo (отмена последнего изменения) и Redo (повтор последнего отмененного изменения) спокойно тоже реализуются на этих же командах. Единственно, если объект тяжелый, то можно реализовать изменение его "тяжелой" части в отдельной custom-команде, но не такой уж часто встречающийся случай.

A>А если в одной форме показывается список сотрудников, в другой выводится статискика по клиентам, в третьей управление сервером, то у вас будет куча команд. Охота вам их писать? даже если охота врятли их наличие сделает код приложения более ясным и понятным.
Какая куча команд, о чем вы вообще? Вроде по-русски пишу...
Попытаюсь найти точки понимания...

1. Говоря про кучу, вы имеете в виду что: объекты (экземпляры) или классы?
   
2. Однаково ли мы понимаем термин "каркас"? Я позаимствовал его у GoF, как один из методов повторного использования кода, а вы как его понимаете?

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

A>Было б очень любопытно посмотреть как используется MVP а рабочем проекте, примерам я не очень доверяю .
A>Не поделитесь кодом как это всё выглядит в рабочем проекте? Если есть юнит тесты этого хозяйства то вдвойне любопытно .

Я постараюсь подготовить пример.

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

A>Я пошёл по тому пути который мне показался наиболее простым и прямым. Организовывать ли общение через события или через интерфейс для меня не принципиально и суть проблемы не в этом. Сразу спрошу, что вы конкретно использовали? Дело в том, что то как, это можно организовать, я вобщем и цлом вполне могу представить, интересует как это используют на практике. Первое моё ощущение — много лишней работы, геморрно писать юнит тесты при сомнительных плюсах . поэтому хотелось бы понять в чём моя ошибка.
Основная ошибка(без обид), думаю, отсутствие опыта работы с большими проектами, где подобный код через некоторое время приводит к катастрофе. Когда тебе ставят задачу написать программу сложения двух чисел ты не почувствуешь большую пользу от классов. Пользу от классов начнешь ощущать когда проект будет несколько сложнее HelloWorld. Так же и с более высокоуровневыми конструкциями и практиками: польза от них ощущается лишь при решении соответствующих задач. Поэтому в примерах того же MVP программист, перелопативший кучу Document-View кода увидит решение проблем с которыми он сталкивался, а вот программист, который решал задачи уровня две-три формы да база с парой таблиц, увидит лишь идею, но не оценит ее практической красоты. Подумай на досуге, как бы ты решил следующую проблему: http://rsdn.ru/forum/message/2680058.1.aspx

Автор: 6lackbird
Дата: 04.10.07

. В рамках MVC/MVP она решается очень красиво и просто.

A>Параметризовать можно всё, но насколько это будт юзабельно и не офигеешь ли писать такие юнит тесты . Примерчик не кинете?

A>В каждой второй статье по MVC/MVP пишут, как просто будет менять отип View без смены контроллера. Но проблема в том, что в 99% случаев и не потребуется этого делать, ровно как и не потребуется аттачить кучу вьюшек к одному контроллеру.
Возможность легко заменить view — это показатель грамотно написанного и продуманного контроллера(и интерфейса view). Это значит, что такой контроллер слабо зависит от конкретной реализации view и его код решает строго ограниченные задачи. Это в свою очередь говорит о том, что такой код будет легче поддерживать. Также такой код более эффективно тестируется, а это значит, что приложение будет более надежным. Иногда, чтобы понять насколько хорошо продуман интерфейс вью и контроллер я пытаюсь представить, а можно ли написать, например, консольную реализацию view? Если не получается, то это повод задуматься над поиском более удачного решения.

A>Вы представляете скольок это будет стоить? Вместо того, что бы в обработчике клика по кнопке вызвать _txtSignalValue.Text = 10, надо отфорвордить вызов в контроллер, в контроллере сформировать команду, отправить её во View, который её распакует и сделает действие запрошенно. И так на каждый чих в каждой форме.
Это мелочи, на фоне сколько ресурсов жрет UI.

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

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

A>>Я пошёл по тому пути который мне показался наиболее простым и прямым. Организовывать ли общение через события или через интерфейс для меня не принципиально и суть проблемы не в этом. Сразу спрошу, что вы конкретно использовали? Дело в том, что то как, это можно организовать, я вобщем и цлом вполне могу представить, интересует как это используют на практике. Первое моё ощущение — много лишней работы, геморрно писать юнит тесты при сомнительных плюсах . поэтому хотелось бы понять в чём моя ошибка.
MVK>Основная ошибка(без обид), думаю, отсутствие опыта работы с большими проектами, где подобный код через некоторое время приводит к катастрофе.
Работал с очень немаленькими проектами, катострофы не наблюдал, с тестами правда беда. например, наблюдал сишный код с WndProc, растянутым на штук 15 станиц. То есть вся обработка событий находится в оконной функции! Накопилось это чудо лет за 10 поддержки очень немаленькой программульки. Но при этом написать новый обработчик или переработать имеющийся вобщем то было несложно и в большинстве случаев эта проблема решалась быстро как ни странно .

A>>В каждой второй статье по MVC/MVP пишут, как просто будет менять отип View без смены контроллера. Но проблема в том, что в 99% случаев и не потребуется этого делать, ровно как и не потребуется аттачить кучу вьюшек к одному контроллеру.
MVK>Возможность легко заменить view — это показатель грамотно написанного и продуманного контроллера(и интерфейса view). Это значит, что такой контроллер слабо зависит от конкретной реализации view и его код решает строго ограниченные задачи. Это в свою очередь говорит о том, что такой код будет легче поддерживать. Также такой код более эффективно тестируется, а это значит, что приложение будет более надежным. Иногда, чтобы понять насколько хорошо продуман интерфейс вью и контроллер я пытаюсь представить, а можно ли написать, например, консольную реализацию view? Если не получается, то это повод задуматься над поиском более удачного решения.
Я говорил немого не о том. Просто если в проекте заморачиваться на написание и обдумывания контроллера для каждой формы, уйдёт значительно больше времени на реализацию. Без контроллера формы пишутся в IDE в высшей степени быстро. создал форму накидал обработчиков, в обрабртчиках отфорвордил запросы соответсвующим службам.

A>>Вы представляете скольок это будет стоить? Вместо того, что бы в обработчике клика по кнопке вызвать _txtSignalValue.Text = 10, надо отфорвордить вызов в контроллер, в контроллере сформировать команду, отправить её во View, который её распакует и сделает действие запрошенно. И так на каждый чих в каждой форме.
MVK>Это мелочи, на фоне сколько ресурсов жрет UI.
Но не мелочи по сравнению с объёмом лишнего кода без контроллеров.

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

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

A>>Было б очень любопытно посмотреть как используется MVP а рабочем проекте, примерам я не очень доверяю .
A>>Не поделитесь кодом как это всё выглядит в рабочем проекте? Если есть юнит тесты этого хозяйства то вдвойне любопытно .

MVK>Я постараюсь подготовить пример.
спасибо, жду

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

A>Работал с очень немаленькими проектами, катострофы не наблюдал, с тестами правда беда. например, наблюдал сишный код с WndProc, растянутым на штук 15 станиц. То есть вся обработка событий находится в оконной функции! Накопилось это чудо лет за 10 поддержки очень немаленькой программульки. Но при этом написать новый обработчик или переработать имеющийся вобщем то было несложно и в большинстве случаев эта проблема решалась быстро как ни странно .
Бывают же чудеса в мире.

A>Я говорил немого не о том. Просто если в проекте заморачиваться на написание и обдумывания контроллера для каждой формы, уйдёт значительно больше времени на реализацию. Без контроллера формы пишутся в IDE в высшей степени быстро. создал форму накидал обработчиков, в обрабртчиках отфорвордил запросы соответсвующим службам.
Вы путаете форму с представлением, стоит еще повнимательнее почитать материалы по MVC... и GoF-ов (конкретно про каркасы приложений).

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

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

A>>Работал с очень немаленькими проектами, катострофы не наблюдал, с тестами правда беда. например, наблюдал сишный код с WndProc, растянутым на штук 15 станиц. То есть вся обработка событий находится в оконной функции! Накопилось это чудо лет за 10 поддержки очень немаленькой программульки. Но при этом написать новый обработчик или переработать имеющийся вобщем то было несложно и в большинстве случаев эта проблема решалась быстро как ни странно .
R>Бывают же чудеса в мире.
Ничего чудесного не вижу. Просто понятие "сопровождения кода" в настоящий момент малёк извращено и преувеличено .

R>Вы путаете форму с представлением, стоит еще повнимательнее почитать материалы по MVC... и GoF-ов (конкретно про каркасы приложений).
Не думаю что я что то путаю, просты Вы ориентируетесь на один пример конкретный пример, где куча форм реализует один и тот же IView видимо. Форма реализует интерфейс представления IView. Так вот, в большинстве случаев каждая форма будет характеризоваться своим IView и своей логикой работы.

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

A>Ничего чудесного не вижу. Просто понятие "сопровождения кода" в настоящий момент малёк извращено и преувеличено .
Ню-ню.

A>Не думаю что я что то путаю, просты Вы ориентируетесь на один пример конкретный пример, где куча форм реализует один и тот же IView видимо. Форма реализует интерфейс представления IView. Так вот, в большинстве случаев каждая форма будет характеризоваться своим IView и своей логикой работы.
Чем представление (у вас интерфейс IView) может ограничить индивидуальность формы и логику ее работы (только на самом деле логика, если имеется в виду не логика поведения ГИПа, должна быть зашита в контроллере)?

Здравствуйте, MaximVK, Вы писали:
MVK>Подумай на досуге, как бы ты решил следующую проблему: http://rsdn.ru/forum/message/2680058.1.aspx

Автор: 6lackbird
Дата: 04.10.07

. В рамках MVC/MVP она решается очень красиво и просто.

Типичная задача для демонстрации красоты MVC , как раз новичка она бы впечатлила, а вот когда под рукой проекты с десятками форм, возникают сомнения в целесообразности очень серьёзные...

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

MVK>Основная ошибка(без обид), думаю, отсутствие опыта работы с большими проектами, где подобный код через некоторое время приводит к катастрофе. Когда тебе ставят задачу написать программу сложения двух чисел ты не почувствуешь большую пользу от классов. Пользу от классов начнешь ощущать когда проект будет несколько сложнее HelloWorld. Так же и с более высокоуровневыми конструкциями и практиками: польза от них ощущается лишь при решении соответствующих задач. Поэтому в примерах того же MVP программист, перелопативший кучу Document-View кода увидит решение проблем с которыми он сталкивался, а вот программист, который решал задачи уровня две-три формы да база с парой таблиц, увидит лишь идею, но не оценит ее практической красоты. Подумай на досуге, как бы ты решил следующую проблему: http://rsdn.ru/forum/message/2680058.1.aspx

Автор: 6lackbird
Дата: 04.10.07

. В рамках MVC/MVP она решается очень красиво и просто.

У меня прямо противоположный опыт (я как раз работаю с большими проектами) — проекты, написанные с сотнями команд-контроллеров-представлений и т.д. становится невозможно поддерживать и очень тяжело в них разобраться человеку со стороны. Собственно, в настоящий момент я как раз начал переписывать один такой завалившийся (а ведь говорили людям, что этим и закончится...) проект (~800 классов, контроллеры-представления-команды, хибернейт, DDD и прочие "best practices") на гораздо более выразительную связку Views<->BL<->DAL(BLT). Снял метрики кода с существующего проекта, интересно будет сравнить с новым вариантом. Хотя понятно, что можно было написать неплохой продукт и с такой архитектурой — скорее, это просто вопрос предпочтений.

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

A>У меня прямо противоположный опыт (я как раз работаю с большими проектами) — проекты, написанные с сотнями команд-контроллеров-представлений и т.д. становится невозможно поддерживать и очень тяжело в них разобраться человеку со стороны. Собственно, в настоящий момент я как раз начал переписывать один такой завалившийся (а ведь говорили людям, что этим и закончится...) проект (~800 классов, контроллеры-представления-команды, хибернейт, DDD и прочие "best practices") на гораздо более выразительную связку Views<->BL<->DAL(BLT). Снял метрики кода с существующего проекта, интересно будет сравнить с новым вариантом. Хотя понятно, что можно было написать неплохой продукт и с такой архитектурой — скорее, это просто вопрос предпочтений.
Обязательно напиши о результатах. Вопрос крайне интересный; большинство из success stories не поддерживаются альтернативными примерами.
Я имел опыт завала проекта, построенного на Best Practices.