100% согласен. Более того, когда наберешся опыта придешь к своему MVC. Гораздо более важен правильный ООП, зачастую это даже по структуре проекта видно, когда службы (классы общающиеся с сервером) лежат в отдельных пакетах, ui - компоненты в отдельном, все абстрагировано, каждый класс решает свою задачу, и неважно как это называется MVC или MVCS и т.п. Новичок же когда берется реализовывать чужие, навороченные способы организации кода, зачастую тонет в проекте. Лучше уж тогда пробуйте готовые архитектурные фреймворки типа pureMVC или Robotlegs, и то браться за них стоит минимум через полгода - год интенсивного программирования.

Добавлено через 39 секунд
А так MVC ради MVC это не всегда оправдано.

Извиняюсь :)
Но книжки могли бы и скинуть.

Абсолютно излишне, даже вредно, читать про паттерны в контексте языка. Одна из самых замечательных книг по этому вопросу: Паттерны проектирования, банды четырех. Ее несложно нагуглить.
Любой паттерн ради паттерна не оправдан. MVC, как и любой другой шаблон, призван решить конкретную задачу, схожую во многих проектах, а именно: отделить логику кода от представления. Или, если вам будет угодно, отделить бизнес-логику от клиентской. Для чего это делается уже вопрос другой, и ответами на него только что не все заборы еще исписаны. Достаточно гуглануть и почитать. Не надо приплетать к одному шаблону другой и городить из этого спагетти. ООП это ООП, MVC это MVC. Одно от другого не зависит нисколько и прекрасно существует по раздельности.
Да-Да. Именно к своему. А так же к своему кодстайлу, к своему видению "как правильно" и прочей замечательной вермишели, которая нас всех так радует, когда мы попадаем в команды, поддерживающие проекты, написанные двумя-тремя подобными профессионалами.

На мой взгляд - ОПП, это правила, MVC, это реализация ОПП, то есть, ОПП и MVC взаимосвязаны.
Меня бросает в дрож от этих слов. Я учился на MVC где модель диспатчит события во вью, вью диспатчит контроллеру, контроллер изменяет ( иногда что-то предает ) в модель. Эта модель реализации, накладывает некие ограничения на структуру написания кода и мне страшно представить, что я попаду в команду, где контроллер слушает модель и изменяет вью ( эта реализация более распространена чем та, на которой учился я ). И читая слова процитированные выше, я опасаюсь попасть в команду, где вью изменяет модель...

Все эти структуры могут применяться в различных ситуациях с разным успехом.
Поэтому одной конкретной нельзя придерживаться всё время.

Ну таких людей на самом деле нет. Так не пишут. Контроллер может ВЫЗЫВАТЬ метода вью, но никак не менять ее значения, контроллер может слушать модель, точно так же как и вью - ничего в этом плохого нет. А вот изменять модель через вью - это уже фарш. Как раз вот со временем МВС становится более широким, чем в стандартной реализации, он может сочетать в себе MVP отдельно, например.
Еще есть такие вещи как вью-контролы, которые конечно очень редки но имеют место быть. Он как бы вьюха, но по большей части занимается процессами.
В одном из проектов был выбор ( понятное дело, что это разовая ситуация, если бы их было много, я бы пересмотрел архитектуру) - либо рассылать событие из вью в контроллер чтобы сделать следующее model.nextGen() - запустить некий метод модели, либо прям из вьюхи это сделать. Почему нет, когда это удобнее и быстрее, лишь потому, что становится уже не МВС - а некая своя стандартизация ? Так это хорошо, чем плохо. Но опять же, это разовая система, я бы писать так не стал постоянно, например.

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

Кстати, может есть описание конвенций синтаксиса на русском где-то?

Например, вот.

Этот камушек преткновения появляется, когда Модель недостаточно абстрагирована и вам кажется, что она должна хранить всякую чушь. Но она не должна. Действительно не должна. Если какие-то вызовы и передачу данных Вам удалось сделать внутри Вью минуя Модель, значит для Модели это и была чушь. Значит, так И НАДО БЫЛО делать. Это не исключение, это и есть норма. Модели это не надо — ну и отлично. Вью должна уметь сама разбираться со своими внутренними проблемами. Модель не обязана помнить все состояния кнопочек при движении мышки по экрану и прочую лабуду. Это не данные уровня Модели. Это данные уровня Вью. Как только появятся данные уровня Модели, Вы не сможете обойтись без записи их в Модель, никак.

Как бы получилось немного не по делу наверное ответ, так как я не сказал о чем речь. Попробую пояснить.
Имеется меню. В котором есть чекБокс допустим, я выбираю состояние, это все во вью. Благодаря тому, что я выбрал состояние, модель должна запомнить это состояние и дальше произвести несколько своих операций, разослать события в другие вью и т.п. - не суть, архитектура допустим большая.
Так вот по парадигме я должен сделать следующее : разослать событие из ВЬЮ в контрол, где сообщить какое состояние выбрано и затем запустить метод модели. Это долгая операция, но она вполне оправда в контекте МВС. Но в данный момент, допустим это разовое дело, КОГДА вью должно в итоге загрузить модель, в остальных случаях - вью только слушает модель. Посему я разрешил себе написать model.nextGen() / model.prevGen() из вью, где выбрано состояние, чем осуществлять ДОЛГИЙ подход через контроллер. В данный момент я и назвал такой вид, как вид-контроллер по сути. Но я повторил, что это разовая практика, я так не делаю, только в 1 проекте позволил - и не увидел проблем, а только плюсы. Опять же зависит от масштабности проекта, но все же..