Почему MVC-архитектуру не называют чистой?

Почему MVC-архитектура не является чистой

MVC (Model-View-Controller) — исторически важная архитектура, но по современным стандартам она не считается полностью чистой архитектурой. Вот основные причины:

1. Нарушение принципа разделения зависимостей

В классической MVC зависимости идут неправильным направлением:

Внешний мир (UI, БД, API)
        ↓
  Controller
     ↙   ↘
  View   Model
        ↓
  Бизнес-логика

Проблема: Controller и View имеют прямые зависимости от Model и внешних сервисов (БД, HTTP). Это нарушает инверсию зависимостей.

Чистая архитектура требует обратного направления:

Внешний мир
    ↓
 Interface
    ↓
 Бизнес-логика (ядро)
    ↑
 Domain

2. Model слишком перегружен ответственностью

В MVC Model обычно содержит:

• Бизнес-логику
• Логику доступа к данным (ORM)
• Валидацию
• Трансформацию данных

# Типичный MVC Model
class User(models.Model):
    # ORM (database layer)
    id = models.IntegerField(primary_key=True)
    name = models.CharField(max_length=100)
    email = models.EmailField()
    
    # Бизнес-логика
    def calculate_reputation(self):
        return self.posts.count() * 10 + self.comments.count()
    
    def send_email(self, subject, body):
        # Логика отправки email
        send_mail(subject, body, self.email)
    
    # Валидация
    def clean(self):
        if User.objects.filter(email=self.email).exists():
            raise ValidationError("Email already exists")

Это нарушает Single Responsibility Principle — один класс имеет слишком много причин для изменения.

3. View зависит от Model

# View прямо обращается к Model
class UserListView(View):
    def get(self, request):
        users = User.objects.filter(is_active=True)  # Прямая зависимость
        return render(request, "users.html", {"users": users})

Проблема: View не может работать без Model. Они тесно связаны, что усложняет тестирование и переиспользование.

В чистой архитектуре: View получает подготовленные данные через слой Presentation, не зная о Model:

# Чистая архитектура
class GetUsersUseCase:
    def __init__(self, user_repository: UserRepository):
        self.repository = user_repository
    
    def execute(self) -> List[UserDTO]:
        users = self.repository.find_active()
        return [UserDTO.from_user(u) for u in users]

class UserListView(View):
    def __init__(self, get_users_use_case: GetUsersUseCase):
        self.use_case = get_users_use_case
    
    def get(self, request):
        dto_list = self.use_case.execute()
        return render(request, "users.html", {"users": dto_list})

4. Controller связан с внешними деталями

# MVC Controller
class UserController(ViewSet):
    queryset = User.objects.all()
    serializer_class = UserSerializer
    
    def create(self, request):
        # Прямая работа с БД
        serializer = self.serializer_class(data=request.data)
        if serializer.is_valid():
            serializer.save()  # ORM operation
            return Response(serializer.data, status=201)
        return Response(serializer.errors, status=400)

Проблема: Controller знает о БД, HTTP Framework, сериализации. Это детали реализации, не бизнес-логика.

5. Сложность тестирования

В MVC сложно тестировать бизнес-логику без внешних зависимостей:

# Сложный тест MVC
class TestUserModel(TestCase):
    def test_calculate_reputation(self):
        # Нужно создавать реальные записи в БД
        user = User.objects.create(name="John")
        Post.objects.create(user=user)
        Post.objects.create(user=user)
        Comment.objects.create(user=user)
        
        # Тестируем бизнес-логику, но зависим от БД
        self.assertEqual(user.calculate_reputation(), 25)

В чистой архитектуре: бизнес-логика тестируется отдельно от инфраструктуры:

# Простой тест чистой архитектуры
def test_calculate_reputation():
    user = User(name="John", posts=2, comments=1)
    assert user.calculate_reputation() == 25

6. Отсутствие явного слоя бизнес-логики

В MVC нет отдельного слоя для Use Cases. Логика распределена между Model, View и Controller:

MVC структура:
├── Model (бизнес-логика + ORM)
├── View (представление + логика вывода)
└── Controller (обработка запросов)

Чистая архитектура:
├── Domain (сущности, исключения)
├── Application (Use Cases, DTOs)
├── Infrastructure (БД, HTTP, логирование)
└── Presentation (Controllers, Views)

7. Framework coupling

В MVC компоненты часто наследуются от Framework классов:

# Привязка к Django
from django.db import models
from django.views import View

class User(models.Model):  # Зависит от Django ORM
    pass

class UserView(View):  # Зависит от Django View
    pass

Проблема: Сложно переходить на другой Framework или переиспользовать код.

Чистая архитектура: Domain слой не зависит от Framework:

# Независимо от Framework
class User:
    def __init__(self, id: int, name: str, email: str):
        self.id = id
        self.name = name
        self.email = email
    
    def is_valid(self) -> bool:
        return bool(self.name) and "@" in self.email

Сравнение MVC vs Clean Architecture

Когда MVC все еще полезна

MVC хороша для:

• Маленьких проектов с простой логикой
• CRUD приложений без сложной бизнес-логики
• Быстрого прототипирования
• 団队 знакомого с MVC (Django, Rails сообщество)

Но для больших систем рекомендуется:

• Hexagonal Architecture (Ports & Adapters)
• Clean Architecture (Robert C. Martin)
• CQRS для сложных операций
• Event-Driven Architecture для распределённых систем

Итоговый вывод

MVC не считается полностью чистой архитектурой потому, что:

1. Зависимости идут в оба направления
2. Model перегружена ответственностью
3. Отсутствует явный слой бизнес-логики
4. Высокая связанность с Framework
5. Сложнее тестировать
6. Нарушает SOLID принципы

Для критичных приложений рекомендуется использовать Clean Architecture или Hexagonal Architecture, которые обеспечивают лучшую масштабируемость, тестируемость и независимость от фреймворков.