Что думает all?

Согласен.

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

Возможно я устарел, но я думаю, что rtfm

велосипед на тему mvc?

/thread

Нужно, если думаете писать вторую графическую обёртку. Иначе нет смысла.

Так вот я о чём и говорю. Как по мне одного класса вместо трёх вполне себе достаточно. Зачем усложнять и менять что-то в трёх местах (а менять всё равно придётся) при добавлении функционала, если можно это сделать в одном месте..

А да, здесь не упомянут ui файл, который как бы отдельно в private секции DialogUi

Интересно. Об этом не подумал, спасибо.

В этом случае два класса достаточно вроде бы, нет? ui и ctl, зачем связующий с сигнал-слотами?

Это очень хорошее разделение. Как только тебе понадобится сделать новый интерфейс над старой логикой или наоборот, ты поймешь. Плюс, это облегчает тестирование логики.

Может, я чего-то не понимаю в MV*, но

Класс DialogCtl имеет дело с внутренними структурами, данными и т.п., т.е. там логика.

разве это не view model, а

Класс Dialog используется как связь GUI и контроллера, т.е. данные из ui класса посредством signal-slot передаются в ctl.

разве не контроллер?

Правильно, это самый обычный mvvm

Тогда почему VM называютт DialogCtl?

Как только тебе понадобится сделать новый интерфейс над старой логикой или наоборот, ты поймешь.

Я понял твою мысль. Но почему-то мне кажется, что будь оно всё в одном классе, было бы не сложнее.

Плюс, это облегчает тестирование логики.

Тут ты прав. Но тестирование GUI от этого проще не становится правда.

А вот это интересно. Пойду почитаю.

Эм.. Потому что его так назвал тс?

A criticism of the pattern comes from MVVM creator John Gossman himself,[12] who points out that the overhead in implementing MVVM is «overkill» for simple UI operations. He also states that for larger applications, generalizing the ViewModel becomes more difficult. Moreover, he illustrates that data binding in very large applications can result in considerable memory consumption.

Собсно это то, из-за чего я и начал этот тред. Мне кажется, что приложение при использовании такого подхода становится жирнее, без видимой на то причины.

Это полезно для «раскидистых» по внешнему виду и/или функционалу приложений, во многих случаях.

Ok, спасибо ещё раз.

Затем, чтобы не писать 100500 обработчиков логики, дергающих методы из логики, да и логику можно переделывать, не боясь за то, что где-то что-то поломается и где-то за чем-то не досмотришь, т.к. тебе только Dialog в 90% случаев придётся поправлять.

mvvm

Схоронил.

Если формочка совсем простая то не имеет смысла, средней сложности - опять нет смысла, а если главное окно сложной программы - 100% оправданное разделение.

Если предполагается дальнейшее развитие, то так и стоит в общем делать.