Api_view['POST', 'GET'] против принципов SOLID?
Это не проблема, с которой я сталкиваюсь, это просто открытое обсуждение. в среде Django Rest мы объявляем декоратор @api_view[] и принимаем такой аргумент, как
- ПОЧТА
- ПОЛУЧАТЬ
- ПОМЕЩАТЬ
- УДАЛИТЬ
в моем случае мне разрешено помещать в декоратор более одного аргумента и делать одну функцию более чем одной ответственностью, например
@api_view['POST', 'GET]
def fbv_list(request):`
if request.method == 'POST':
#do something
if request.method == 'GET':
#do something
в этом случае fbv_list делает более одной вещи, которая является POST и GET разве в этом случае эта функция не противоречит Единому классу ответственности, который соответствует принципам SOLID ????
Это мой вопрос, и если да, то что нужно сделать, чтобы не сломать SOLID .
Заранее спасибо.
Ответы 2
На мой взгляд, вы не нарушаете никаких правил. С помощью одной функции вы обрабатываете один объект. Таким образом, вы экономите строки/печать, что облегчает чтение и отладку в дальнейшем. Нарушение правил будет, если ваш get обрабатывает один объект, а post обрабатывает другой. Было бы адом отлаживать это, если что-то не работает.
(Мое мнение).
Я начну свой ответ, процитировав определение представления из официальных документов Django:
Функция представления, или сокращенно представление, — это функция Python, которая принимает веб-запрос и возвращает веб-ответ. Этот ответ может быть HTML содержимое веб-страницы, или перенаправление, или ошибка 404, или XML документ или изображение. . . или что-нибудь, на самом деле. Сам вид содержит любую произвольную логику, необходимую для возврата этого ответ.
Ответственность представления состоит в том, чтобы принимать веб-запрос в качестве входных данных и возвращать веб-ответ в качестве выходных данных. API-интерфейсы DRF также являются «представлениями», поэтому это определение подходит и для них.
Разбивая это дальше, основная ответственность представления состоит в том, чтобы принять запрос и выполнить «произвольную» логику над ним. Что произвольно? Когда представление получает запрос, как оно решает, какой набор операций необходимо выполнить? Пытается ли запрос получить какую-то информацию из системы, создать запись или, возможно, попытаться выполнить сложную операцию обновления моделей данных? Это то, что должно решить представление, потому что это его основная цель. В зависимости от характера входного запроса тип вывода будет меняться. Тем не менее, основной функционал остался прежним. Это не нарушает SRP. Я также перечисляю один из фрагментов кода из документации Django, который использует тот же шаблон:
from django.http import HttpResponseRedirect
from django.shortcuts import render
from .forms import NameForm
def get_name(request):
# if this is a POST request we need to process the form data
if request.method == 'POST':
# create a form instance and populate it with data from the request:
form = NameForm(request.POST)
# check whether it's valid:
if form.is_valid():
# process the data in form.cleaned_data as required
# ...
# redirect to a new URL:
return HttpResponseRedirect('/thanks/')
# if a GET (or any other method) we'll create a blank form
else:
form = NameForm()
return render(request, 'name.html', {'form': form})
P.S. Обязательно проверьте эту ссылку, чтобы увидеть, как SRP может вводить в заблуждение и насколько его цель и использование субъективны.
Спасибо, Сайед, я не знал, что высокая сплоченность в одном классе не нарушает принцип SRP.