Шаблон проектирования MVC

Паттерн Model-view-controller наверное самый популярный вариант построения web-приложений на сегодняшний день и считается, что если приложение написано без реализации (или хотя бы упоминания) MVC, это совсем не круто :). Все популярные современные фреймворки (Django, Spring MVC, Yii, RoR, asp.net MVC) для построения веб-приложений так или иначе реализуют данный паттерн. В сети полно примеров и показательных реализации MVC шаблона на всех популярных языках, фреймворках и даже CSM, напишу и я несколько строк по этому поводу.
Несмотря на обилие информации, обсуждение MVC зачастую перерастает в жаркие дебаты, а как только дело доходит до практической реализации шаблона, и всплывает вопрос, где размещать бизнес логику, то мнения расходятся. Одни советуют разместить логику в контроллере, другие в модели, даже есть мнения что ее можно "размазать" по всем трем частям шаблона. Просто создав папки model, view, controller и распихав по ним файлы с исходным кодом нельзя реализовать данный паттерн. Так же хочется отметить что шаблон проектирования MVC никак не связан ни с языком разработки ни с ООП. Естественно можно и нужно использовать объектно ориентированный подход вне шаблона MVC, так же как можно (но нужно ли?) реализовать шаблон MVC в процедурном стиле.

Обратимся к определению:

Шаблон MVC позволяет разделить данные, представление и обработку действий пользователя на три отдельных компонента

• Модель (Model). Модель предоставляет данные (обычно для View), а также реагирует на запросы (обычно от контроллера), изменяя своё состояние.
• Представление (View). Отвечает за отображение информации (пользовательский интерфейс).
• Поведение (Controller). Интерпретирует данные, введённые пользователем, и информирует модель и представление о необходимости соответствующей реакции.

Model представляет собой ключевой элемент паттерна и может состоять из нескольких слоев, например слоя доступа к данным (DAO) и слоя бизнес-логики (Service Layer) или быть построена по более сложному паттерну с большим числом абстракций. Это не столь важно, самое главное, что вся бизнес логика в том числе и валидация данных должна находиться именно здесь. Очевидно, что модель должна предоставить интерфейс для взаимодействия с Контроллером, который в свою очередь является "склеивающим" слоем (Glue Layer). Применительно к веб-архитектуре, в Презентационном слое (View) как правило находится либо механизм работы с шаблонами, либо работа с интерфейсами библиотек или даже фреймворков, отвечающих за пользовательский интерфейс. Как и Модель, Представление имеет свой интерфейс, через который и поступают данные из Модели.