Ответ
Подход «Толстые модели, тонкие представления» (Fat Models, Thin Views) — это паттерн проектирования в Django, при котором основная бизнес-логика, связанная с данными, размещается непосредственно в методах моделей, а не в представлениях (views) или сервисных слоях.
Ключевая идея: Модель должна быть не просто описанием полей в базе данных, а полноценным объектом, который «знает», как управлять своими данными и выполнять связанные с ними операции.
Преимущества:
- Централизация логики: Вся логика, относящаяся к конкретной сущности (например,
Order), находится в одном месте — классеOrder. Это упрощает её поиск и понимание. - Переиспользование кода (DRY): Методы модели можно вызывать из представлений, тестов, административной панели или Celery-задач, избегая дублирования.
- Упрощенное тестирование: Легче писать юнит-тесты для методов модели, изолируя их от HTTP-запросов и других компонентов фреймворка.
Пример:
Вместо того чтобы размещать логику оплаты в представлении, её выносят в метод модели Order.
# models.py
from django.db import models
from django.utils import timezone
class Order(models.Model):
# ... поля модели
total_price = models.DecimalField(max_digits=10, decimal_places=2)
paid_at = models.DateTimeField(null=True, blank=True)
def is_paid(self):
"""Проверяет, оплачен ли заказ."""
return self.paid_at is not None
def mark_as_paid(self):
"""Отмечает заказ как оплаченный."""
if not self.is_paid():
self.paid_at = timezone.now()
self.save(update_fields=['paid_at'])
# Здесь можно отправить уведомление клиенту
# send_payment_confirmation(self.customer)
# views.py
def process_payment_view(request, order_id):
order = Order.objects.get(pk=order_id)
# Логика обработки платежа...
if payment_successful:
order.mark_as_paid() # <-- Вся логика инкапсулирована в модели
# ...Когда стоит быть осторожным:
При слишком большом объеме логики модель может нарушить принцип единственной ответственности (SRP). В таких случаях сложную логику лучше выносить в отдельные менеджеры моделей (models.Manager) или сервисные классы.