Comments 47
Нарушение принцыпа
Вообще-то, принцИпа.
Спасибо! Поправил
Ну и поТдерживать и проЭкт - туда же
А вообще, на этот шаблон нужно смотреть как на родственника ООП:
Модель, это данные, как они есть внутри
view, это способ представления данных наружу
На а контроллер, это и есть методы...
Если на жту концепцию взглянуть так, то не нужно будет мешать это с ООП. Это просто альтернатива,... абстракция
MVC (Model–View–Controller) – это архитектурный шаблон, предложенный Тригве Ренскаугом в конце 1970., который разделяет код на три части: модель (данные и бизнес-логика), представление (UI) и контроллер (обработчик запросов).
Я бы выделил, для оконных приложений, на C++/WTL, другие принципы:
Менеджер потоков.
Менеджер видов (дочерних окон)
Менеджер событий (для программной и бизнес логики, в том числе).
Посмотрим, чем SOLID может быть полезным для моих программ (пет-проектов на C++/WTL):
S - Класс должен иметь только одну причину для изменения.
Непонятная формулировка. Кем изменяется, своей программой или чужой?
O - Классы должны быть открыты для расширения, но закрыты для модификации.
То же самое. Для собственных пет-проектов это не актуально.
L - Подклассы контроллеров меняют поведение базового класса.
То же самое.
I - Клиенты не должны зависеть от интерфейсов, которые они не используют.
Согласен.
D - Модули высокого уровня не должны зависеть от модулей низкого уровня. Оба должны зависеть от абстракций.
Модули в С++ имеют неоднозначное толкование. Для классов может быть и так и не так.
В общем, SOLID мне не нужен. Более подходит метод «здравого смысла». Ну, если рассуждать, как в анекдоте: «– Ненавижу Карузо! – О-о-о! А где вы его слушали? – Да, мне Мойша по телефону напел!».
Пойдем дальше:
DRY (Don't Repeat Yourself)
Достаточно очевидно, как для метода «здравого смысла».
KISS (Keep It Simple, Stupid)
То же самое.
GRASP (General Responsibility Assignment Software Patterns) :
Information Expert : Ответственность должна назначаться классу, который имеет необходимую информацию для ее выполнения.
Достаточно очевидно.
Creator: Класс A должен создавать экземпляры класса B, если A содержит B, агрегирует B, или имеет данные для инициализации B.
То же самое.
Controller (Контроллер в смысле GRASP): Не-UI объект должен обрабатывать системные события и координировать работу.
Непонятно и не кажется важным.
Low Coupling (Слабая связанность): Классы должны иметь минимальную зависимость друг от друга.
High Cohesion (Высокая связность) Элементы класса должны работать вместе для достижения общей цели.
Слишком общие формулировки, чтобы иметь неочевидный смысл.
Polymorphism (Полиморфизм): Используйте полиморфные операции вместо условий типа.
Чистый ООП?
Pure Fabrication (Чистая выдумка): Создавайте искусственные классы для достижения низкой связанности и высокой связности.
Без проекции на программную реализацию конкретной модели, не имеет явного смысла.
Indirection (Перенаправление): Избегайте прямых связей между компонентами, используя промежуточные объекты.
То же самое.
Мне всегда было влом разбираться с новомодными принципами программирования. И вот появился повод, посмотреть на них хотя бы краем глаза. В итоге, остался при своем мнении: Самый надежный принцип: метод «здравого смысла». Пока он меня еще не подводил…
Я бы выделил, для оконных приложений, на C++/WTL
Плюсую. Реализация классического MVC в вебе технически невозможна (без сокетов, лонг-поллинга или других костылей).
Серверное ПО (Symfony, Laravel, etc) в подавляющем большинстве случаев использует MVP архитектуру (если исключить специфику веба, вроде роутера и прочих).
Когда ты работаешь один, здравый смысл — это хороший ориентир. Но как только в проекте появляется команда, особенно разная по опыту, контексту и подходам — здравый смысл становится субъективным и конфликтующим. Вот тут и становятся полезны принципы вроде SOLID, DRY, KISS, GRASP — как общий язык, как инструмент договорённостей.
SOLID не панацея — действительно, применять эти принципы бездумно — может быть избыточно. Формулировки в книгах часто абстрактны и требуют практического опыта, чтобы стать «осознанными».
DRY, KISS, GRASP, Low Coupling / High Cohesion — действительно, интуитивно понятны, особенно для опытного разработчика.
В целом, если мы говорим о пет-проектах - можно писать как хочешь. Главное чтобы ты их понял через пол года когда нужно будет править свой же код) Но если твой пет-проек взлетит и ты захочешь на него нанять команду разработки а то и не одну. Нужно быть готовым к его изменениям и стандартизации подходов разработки
Когда ты работаешь один, здравый смысл — это хороший ориентир. Но как только в проекте появляется команда, особенно разная по опыту, контексту и подходам — здравый смысл становится субъективным и конфликтующим. Вот тут и становятся полезны принципы вроде SOLID, DRY, KISS, GRASP — как общий язык, как инструмент договорённостей.
«Конфликтующими» будут и все перечисленные вами концепции. Ибо в них не более содержательных мыслей, чем в формулировке «здравый смысл». Все эти примеры, в виде «потоков сознания», ничего толком не объясняют и ни на что особо не мотивируют. Ну, зачем мне абстрактный код по веб-программированию, если он осмысленно не проецируется на более привычный мне С++? Почему нельзя демонстрировать концепции на реальных демонстрационных программах? Общих разговоров – сколько угодно, а конкретных – ноль. Вот и приходится изобретать практические концепции программирования самому, как я это делал в статье: «Модульное программирование в C++. Статические и динамические плагины» – https://habr.com/ru/articles/566864/ . Поскольку, материалы такого рода, с разбегу, не отыщешь.
Проблема даже не в абстрактных рассуждениях (для математика, окончившего мехмат МГУ, это не ограничение), а в их содержательной неопределенности, которую можно толковать как угодно. Другими словами, не чувствуется в них потенциальной силы. Что принуждает думать о собственных «велосипедах».
В целом, если мы говорим о пет-проектах - можно писать как хочешь. Главное чтобы ты их понял через пол года когда нужно будет править свой же код)
Это, действительно, актуально. Только, концепции программирования, которые на слуху, мало в чем помогают, ну, разве, в какой-то мере, ООП. Поэтому, задумываясь о следующих версиях своих пет-проектов, приходится придумывать что-то новое, либо, «переоткрывать Америку».
Но если твой пет-проек взлетит и ты захочешь на него нанять команду разработки а то и не одну. Нужно быть готовым к его изменениям и стандартизации подходов разработки
Мой пет-проект, на базе обучающей программы «L'ecole» ( https://habr.com/ru/articles/848836/ ), вполне может взлететь. Тем более, что для нее создана (неопубликованная) программ «МедиаТекст» (см. скриншот: http://scholium.webservis.ru/Pics/MediaText.png ), подготовки данных плюс заканчиваю скрип на Питоне, по распознаванию встроенных субтитров видео и т.п.
Только, вот, нужно ли здесь нанимать «команду разработки» – не уверен. Если хотят, пусть делают собственный форк по моему прототипу, но мне «команда» не нужна. Используемые программы относительно простые, проще их доводить до ума самому, чем объяснять, чего хочешь и как этого достичь. Главное, по моему мнению, это данные (уроки) к программе, здесь каждый может приложится, если ему не влом, как, скажем, ваяют свои варианты «карточек», для «Анки».
А по «стандартизации подходов разработки» можно было бы что-нибудь почитать, но ничего путного я не вижу.
Непонятно и не кажется важным.
Low Coupling (Слабая связанность): Классы должны иметь минимальную зависимость друг от друга.
High Cohesion (Высокая связность) Элементы класса должны работать вместе для достижения общей цели
Зря. Учите дальше.
Для сложных систем это очень важно
Зря. Учите дальше.
А когда программы писать? Вы их много написали? Меня мои программы кормили двадцать лет. И все проблемы решались на уровне здравого смысла, а не заучивания малополезных заклинаний.
Для сложных систем это очень важно
Классная у нас аргументация. У меня: «не кажется важным», у вас: «очень важно». Кто прав? Кто последний ответил? :)
"Модель в MVC часто понимается как ORM-объект или ActiveRecord".
Имхо, неверное заявление. Мне кажется, корень статьи идет от неверного понимания М. Скорее всего это было притянуто из-за того, что в Laravel (а примеры из него), модели - это объекты Active Record. Но модель Laravel - это не модель MVC. Как например фасад в Ларавел, не является паттерном "фасад", что подменяет понятия нормального фасада, и куча людей бегает и говорит что фасад - антипаттерн, на основе Ларавел.
Например в Symfony никто не называет объекты ORM - моделью. И не говорят, что entity это M из MVC.
Классический MVC не предлагает явного и самодостаточного слоя для сложной, чистой бизнес-логики
Модель - это слой логики отделенный от слоя транспорта и представления, всё и ничего более. Дробить саму Модель на другие слои (домен, апилекейшен, инфра), сложные структуры - да пожалуйста.
Просто ранее и этого не было, писали все в одном файле образно article_page.php, где доставались данные из $_GET, там же ходили в БД, там же формировали html.
И то, что теперь кажется Вам дефолтом, который предоставляет любой фрейморк - это и есть MVC. Ну если уж совсем не ушли в Fat Controller.
В общем,имхо, статья красивая, объемная, но понимание Model в MVC неверное. У вас из коробки фреймворка MVC - контроллер, View - рендеррер ,Model - логика. А если копнуть чуть глубже, то скорее даже MVP, потому что модели не ходят в view как в классической схеме. Так что, вы используете этот паттерн постоянно на автомате, а уже на основе него другие архитектуры и подходы используете.
Спасибо за развёрнутый комментарий — это действительно важное уточнение. 🙌
Вы абсолютно правы: во многих популярных фреймворках термин "модель" часто упрощён до ORM-сущности, что приводит к недопониманию сути "Model" в MVC.
Так как статья написана для начинающих свой путь в разработки, я боюсь предположить что "M" к сожалению будет понята именно так как я описал в стате.
Я думаю что стоит обновить статью и добавить ваше замечания в нее.
Покажите, пожалуйста, схему, где в MVC модель ходит во вью?
Эта стрелка отражает подписку вью на модель используя паттерн "наблюдатель", который как раз был популяризован благодаря smalltalk. Возьмём какой-нибудь терминал для оплаты. Модель в этом случае это не только бизнес-модель, но и например состояние чекбокса или меню. Контроллер это обработчик нажатий на клавиатуре терминала (реализовано черед механизм всплытия события в фреймворке). А вью это движок, который умеет отрисовывать состояние модели на экране по пикселям, так что разработчику не надо делать это вручную. Это в какой-то мере прародитель современной компонентной разработки. Вместо того, чтобы вручную отрисовывать курсором по экрану состояние, в smalltalk создавалась триада контроллер чекбокса, модель чекбокса и вью чекбокса. К модели можно было привязать несколько контроллеров (мышь, клавиатура, нажатие на экран). Можно было заменить вью (кругленький или квадратный чекбокс). И уже потом на нажатие кнопки "применить" с контроллера формировался запрос бизнес и происходила коммуникация с бизнес моделью. Т.е. как в современных UI фреймворкпх можно описать дерево компонентов, только у каждого компонента есть своя триада контроллер, вью, и модель. Сейчас это всё более высокоуровнево и декларативно, нежели императивно как в smalltalk.
MVC в веб это stateless вариация MVC из smalltalk, в которой вью не имеет подписки на модель и управляется контроллером, который выполняет роль Presenter. Так что да, можно сказать, что MVC в веб это MVP. Но это чисто презентационный слой, как и в старые добрые. HTTP запрос заменил клавиатуру как способ ввода; состояние модели либо передается stateless в самом запросе (например в HTML форме), либо при каждом запросе восстанавливается из состояния на сервере; controller/ presenter занимается координацией этого процесса. И вот это фреймворк уже подключается к бизнес модели как движок для управления UI с сервера, не более. Поэтому в контроллере в вебовском MVC должно быть только вызов слоя служб на экшен пользователя и определение следующего экрана и его состояния. Представьте, что это отдельное приложение, даже если в рамках одного хоста у вас и сервисы и презентация. Никакой почты отправлять из контроллеров и не задумывалось, если вы хотите гибкую архитектуру.
В чистом MVC буква М — это не просто ORM, а вся бизнес-логика и доступ к данным, то есть:
- бизнес-правила, работа с базой, валидации, доменные сервисы, агрегаты и т.п. Это не просто сущности (типа User или Product) в Laravel.
Laravel называет "моделью" то, что по DDD называется Entity или Active Record. Это сделано для облегчения разработки и путает неокрепшие умы. В более чистой архитектуре (например, DDD + Hexagonal) Laravel модель будет разделена на:
1. Entity (сущность),
2. Repository (доступ к данным),
3. Service (бизнес-логика),
4. Value Object и пр.
Поэтому согласен с одним из комментаторов, что автор чуть в другую сторону ушёл в понимании MVC. Уместнее данную статью назвать "Проблемы реализации паттерна MVC на примере Laravel фреймворка"
Также согласен! Сделаю обновления
В чистом MVC об ORM и не слышали. Классический MVC паттерн для императивного UI фреймворка из Smalltalk для десктопных приложений и некоторых вариаций embedded систем.
И даже в веб вариации MVC модель это байндинг полей из Body / Query String / Path / Headers, валидация построенной модели (смотри ModelBinders & ModelState & ModelState.IsValid в ASP.NET Core), аутентификация, авторизация. А дальше уже идут вызовы application services, которые предосталяют интерфейсы юз кейсов бизнес логики.
Но MVC будет работать как часы, даже если у вас нет никакой бизнес логики и ваше приложение это просто рендерер статических страниц.
Очередная "навайбкоденная" статья... *глубокий вздох*
MVC нормальная парадигма там, где это уместно. И она никак не противоречит SOLID, DRY, KISS и пр., и не обязывает лепить в коде антипаттерны типа god object, bloated code или high coupling.
Всё зависит от уровня и понимания MVC программистом. Я рассматривал этот паттерн в его базовой интерпретации и хотел предостеречь от некоторых практических ошибок при его применении.
При этом согласен, что грамотно реализованный MVC:
Совместим с SOLID, DRY, KISS принципами
Не приводит к антипаттернам вроде God Object
Остаётся хорошим выбором там, где уместен
У вас, что джуниоры создают структуру проекта и нет ни мидлов ни сеньёров?
Молодежь. Вы начитались книжек и молитесь на них, как на икону. Сами авторы своих принципов не соблюдают. К тому же всё зависит от языка. Переиспользуемость кода, его понятность, чистота и поддерживаемость вполне может быть реализована даже при функциональном программировании. А говно можно налепить и с ООП, и CLEAN и MVC. Куча проектов являются кучей хлама, потому что вы просто озаботились "чистотой кода" но не решением задач пользователя.
Согласен, что плохой код можно написать в любой парадигме — будь то ООП, функциональный стиль или даже Clean Architecture. И да, "чистота ради чистоты" — не цель.
Но реальность такова, что мы решаем задачи бизнеса, которые строятся на проблемах и желаниях пользователей. А решать их нужно быстро, качественно и с минимальными багами. Именно поэтому мы читаем книжки, изучаем паттерны, архитектуры и подходы — не потому что "молимся", а потому что это помогает управлять сложностью и снижать риски на росте продукта.
Если продукт должен быстро эволюционировать, меняться, масштабироваться — без прочной архитектурной базы он просто рассыпается. Поэтому знания принципов — это не фанатизм, а инструмент.
Это все так, но MVC сам по себе не является "антипатерном" или каким-то не тем руководством к действию, как вам уже неоднократно подметили в комментариях. Ваши примеры кода, мягко говоря, притянуты за уши, от MVC у вас просто постфикс Controller и вся логика в нем, но это ваше желание и ваша (нейросети?) реализация контроллера, а не так написано в условном учебнике. Красота архитектуры в руках ее создающего.
MVC полностью реализует логику только в самых простых случаях.
Для сложных случаев MVC естественным образом превращается в адаптер между веб и чистой архитектурой бэка.
Те надо бояться чистой архитектуры
Пример
use axum::{routing::post, extract::State, Json, Router};
use serde::{Deserialize, Serialize};
use std::sync::Arc;
// 1. СЛОЙ ДОМЕНА
struct User { id: String, username: String }
impl User {
fn new(username: String) -> Self {
Self { id: uuid::Uuid::new_v4().to_string(), username }
}
}
// 2. СЛОЙ ИНФРАСТРУКТУРЫ (async)
#[axum::async_trait]
trait UserRepository: Send + Sync { // Send+Sync нужны для потокобезопасности
async fn save(&self, user: &User);
}
struct PostgresUserRepository;
#[axum::async_trait]
impl UserRepository for PostgresUserRepository {
async fn save(&self, user: &User) {
println!("SAVING to DB: User ID {}, Name {}", user.id, user.username);
// Здесь была бы асинхронная работа с БД
}
}
// 3. СЛОЙ ПРИЛОЖЕНИЯ (DTO, метод сервиса async)
#[derive(Deserialize)]
struct CreateUserRequest { username: String }
#[derive(Serialize)]
struct UserViewModel { id: String, username: String }
struct UserService<R: UserRepository> {
repo: Arc<R>, // Используем Arc для DI
}
impl<R: UserRepository> UserService<R> {
async fn create_user(&self, request: CreateUserRequest) -> UserViewModel {
let user = User::new(request.username);
self.repo.save(&user).await;
UserViewModel { id: user.id, username: user.username }
}
}
// Структура для хранения зависимостей (DI Container)
struct AppState {
user_service: UserService<PostgresUserRepository>,
}
// 4. СЛОЙ ПРЕДСТАВЛЕНИЯ/КОНТРОЛЛЕР (реализован на axum)
async fn create_user_handler(
State(state): State<Arc<AppState>>, // Получаем DI-контейнер
Json(payload): Json<CreateUserRequest>, // axum парсит JSON в DTO
) -> Json<UserViewModel> {
// Контроллер просто вызывает сервис и возвращает результат
let view_model = state.user_service.create_user(payload).await;
Json(view_model) // axum сериализует ViewModel в JSON
}
#[tokio::main]
async fn main() {
// 1. Создаем зависимости (Dependency Injection)
let user_repo = Arc::new(PostgresUserRepository);
let user_service = UserService { repo: user_repo };
let app_state = Arc::new(AppState { user_service });
// 2. Создаем роутер и передаем в него зависимости через .with_state()
let app = Router::new()
.route("/users", post(create_user_handler))
.with_state(app_state);
// 3. Запускаем сервер
let listener = tokio::net::TcpListener::bind("0.0.0.0:3000").await.unwrap();
println!("listening on {}", listener.local_addr().unwrap());
axum::serve(listener, app).await.unwrap();
}Всё просто и понятно
Approved, можно мержить!
Что можно подсветить, так это гибкость всего данного решения:
Изменилась стратегия хранилища данных - заменили репозиторий;
Необходимо заскейлится - вынесли application services на другую машину и общаетесь с ней по rpc вместо inmemory;
Необходимо добавить поддержку нового протокола типа gRPC или GraphQL: добавляем.
Нужно подключить RESTFul API - подрубаем MVC фреймворк, который скорее всего уже написан под ваш язык программирования.
90% сценариев расширения приложения покрыто.
Ага.
Каждый слой легко тестировать и заменить. Зависимость от фреймворка в минимальной части кода. Не надо бояться чистой архитектуры.
Сейчас, пожалуй, добавил бы обработку ошибок и типы в домене чтобы запретить некорректные данные.
А можно и в другую сторону ручку открутить до предела. Смешаем все слои. Ни чистой архитектуры ни MVC
Простота и никакой расширяемости.
<?php
// "Роутер" + "Контроллер"
if ($_SERVER['REQUEST_METHOD'] === 'POST' && $_SERVER['REQUEST_URI'] === '/users') {
// 1. Десериализация
$input = json_decode(file_get_contents('php://input'), true);
$username = htmlspecialchars($input['username'] ?? 'guest');
// 2. Создание данных
$user_data = [
'id' => uniqid('user_'),
'username' => $username,
];
// 3. Сохранение в БД (Слой инфраструктуры)
try {
// --- Подключение к БД ---
$dsn = "pgsql:host=localhost;port=5432;dbname=testdb;";
$pdo = new PDO($dsn, 'user', 'password', [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION]);
// --- Подготовка и выполнение запроса ---
$sql = "INSERT INTO users (id, username) VALUES (?, ?)";
$stmt = $pdo->prepare($sql);
$stmt->execute([$user_data['id'], $user_data['username']]);
} catch (PDOException $e) {
// В реальности здесь было бы логирование и корректный ответ об ошибке
http_response_code(500);
echo json_encode(['error' => 'Database error']);
exit;
}
// 4. Ответ клиенту
header('Content-Type: application/json');
echo json_encode($user_data);
} else {
http_response_code(404);
echo 'Not Found';
}
Как mvc влияет на производительность? Хотя я придерживаюсь мнения что буква m в данной аббревиатуре подразумевает всю бизнес логику, но предположим что это только model от AR, то чем меньше слоев тем быстрее приложение. В целом не стоит трогать MVC, это что то старое и доброе, всем давно понятно, что слоев в нормальном приложении намного больше.
MVC-системы (в класическом понимании) работают медленнее по своей природе. Контроллеры тянут за собой огромные зависимости, модели выполняют десятки ненужных запросов к базе данных, а плотная связанность не позволяет эффективно кешировать компоненты. Каждый HTTP-запрос инициализирует половину системы, даже если нужно вернуть простой JSON с одним полем.
1) Каждый вызов — синхронный и всё происходит последовательно, чем больше логики — тем больше времени на выполнение. Нет распараллеливания (никаких событий, очередей, worker'ов). В итоге растет нагруска на сервер
2) Не прямое но все же. Проблема с Кэширование; Нельзя легко выделить результат одной операции и обернуть его в кэш. Кэширование требует ясных границ ответственности.
MVC-системы (в класическом понимании) работают медленнее по своей природе.
Контроллеры тянут за собой огромные зависимости, модели выполняют десятки ненужных запросов к базе данных
Это конкретная реализация, а не правила MVC поймите уже.
Вы ещё и сеньор разработчик...
Спасибо. Я понимаю это. У кого молоток, тому все кажется гвоздем. Фреймворк по умолчанию предлагает структуру, которую легко принять за финальную. И я хотел показать то что не правильноее ее понимания может привести к большим проблемам в будущем.
Вы не говорите что неправильное понимание MVC приводит к этому. Вы что в статье, что в комментариях заявлете что MVC по умолчанию и своему определению это медленно и плохо, еще и проблемы с многопоточностью...это конечно тоже классно выглядит при вашем сеньерстве. По своей сути все паттерны архитектуры приложения сводятся к одному - разделения кода на зоны ответственности. Вы конечно сеньер, и должны такие вещи понимать, как я считаю, но давайте я вам скажу - код необходимо разделять потому-что для логики бизнеса и например подключение и работе к БД вы используете один и тот же язык с одним и тем же кодом плюс минус. Дак вот архитектурный паттерн и нужен что-бы разделить эти зоны ответственности, если вы все это раскидали как попало то проблема не в MVC, тут даже луковичная/гексогональная/"чистая" архитектура не поможет))
Слоистость приложения не создает оверхэд. Оверхэд создает инфраструктура - сетевые вызовы и тд. Но это аксиома распределенных масштабируемых систем, без этого никак. Т.е. пока у вас все слои в одном процессе - это инстанс перфоманс. Но так невозможно скейлится. В любой системе, будь она распределенная или монолитная, самое сложное, что должен делать MVC слой - это парсить запрос, валидировать его и рендерить HTML. Все остальное на слой сервисов.
Чето вы все так усложнили в статье. Будете проще mvc это просто интерфейс. Он не говорит четких границ просто дает логическое основании как делить код на 3 части. Есть большой контроллер. Нужно юзать код в 2х или писать тест? Берем и выделяется код в класс сервис и все! Опираемся от задачи. Нужна обработка бизнес логики не хотим ложить в класс сервис можно сделать например BusinessModel2 и через DI реализовать домен там почему бы и нет? Нужен орм юзаем например ef. Нужно абстрагировать модель к бд для разных типов например то что провайдер ef не поддерживает юзайте класс репозитория и все. Так под любую задачу любой кейс любой масштаб сложности. Ну почему mvc и все а другое юзать то нельзя? Это же не так!
Я уже давно вынашиваю идею написать серию статей об MV* семействе паттернов. Но когда смотрю на объем черновиков по этой теме - ужасаюсь от объема материала. Чтобы реально понять, нужно приводить примеры кода, сравнивать различные реализации (MVC в smalltalk, objective-c/swift и например Angular JS это разные вариации MVC, а это мы еще сервера не коснулись) , делать много анализа. Это уже диссертация получится, которую прочитаешь разве только посвятив ей весь обед. А делать такого рода статьи как данная "кладите код сюда и будет хорошо", при этом очередной раз ретранслируя распространненные заблуждения, я себе позволить не могу.
Хоть я и фуллстек с бОльшим уклоном в бэк, но мне есть что рассказать по этой теме, для новичков так точно. Если интересно, ставь +. Если наберем 50 плюсов на комментарии - подготовлю и выпущу свою статью об MVC в течении месяца.
Несмотря на очевидные недостатки и появление гораздо более эффективных архитектурных решений, MVC продолжает отравлять кодовые базы многих проектов.
Разве причина не в том, что все сказанное в статье можно просто взять и выкинуть. (Для это всего есть частая архитектура, DDD и Микросервисы) Если делать все по правилам, то можно потерять мотивацию изучать программирование.
ИМХО: Я вобще считаю, что изучать паттерны нужно после 2-3 пет проектов на простом MVC.
Спасибо за статью, с интересом прочитал (͡°͜ʖ͡°)
Грехи программиста: MVC