Python-сообщество

Вот те раз! Вот те два Со спрингом то и я могу. На нем сейчас и крутится.

FishHook
Не потому что она плохая сама по себе, а потому что она не подходит для энтерпрайза. Как только вы начинаете думать над архитектурой, джанга начинает мешать и вы потихоньку запиливаете свой фреймворк. Лучше сразу взять что-нибудь минимальное типа фласка или гибкое типа пирамиды. А еще лучше подобнвми делами на питоне не заниматься

vasi.che
Одним из мотивов была переносимость на другой(ие) хосты.

FishHook

vasi.che

FishHook

В общем случае в DRF, если вы хотите в рамках одного вьюсета использовать разные сериализаторы на вход и на выход, у вас нет другого выхода, кроме как городить что то типа

 class CustomSerializerClassesMixin():
    serializer_class = None
    request_serialiser_classes = {}  # {'action': SerializerClass}
    response_serializer_classes = {}
    def get_serializer_class(self):
        if hasattr(self, 'action') and self.action in self.request_serialiser_classes:
            return self.request_serialiser_classes[self.action]
        return self.serializer_class
    def get_response_serializer_class(self):
        if hasattr(self, 'action') and self.action in self.response_serializer_classes:
            return self.response_serializer_classes[self.action]
        return self.serializer_class

Slow
В общем случае в DRF, если вы хотите в рамках одного вьюсета использовать разные сериализаторы на вход и на выход, у вас нет другого выхода, кроме как городить что то типа

 # -*- coding: utf-8 -*-
"""-------------------------------------------------------------"""
class ABussinesLogic:
  """
    Абстрактный класс, родитель для конкретных фунций бизнес-логики
  """
  def __init__(self, validator, processor, serializator):
    self.validator = validator
    self.processor = processor
    self.serializator = serializator
  def isValid(self, data):
    return self.validator.isValid(data)
  def process(self, data):
    return self.processor.process(data) # Сама логика
  def serialize(self, data):
    return self.serializator.serialize(data)
"""-------------------------------------------------------------"""
class DocCreator(ABussinesLogic):
  """
  Конкретная функция бизнес-логики
  """
  def __init__():
    super(someValidator, someProcessor, someSerializator)
"""-------------------------------------------------------------"""
class Router:
  """
  Обработчи маршрутов и методов
  """
  """
    Конфиг для REST. Вид:
    route: {
      {
        method1: BussinesLogic1(),
        method2: BussinesLogic2()
      }
    }
  """
  config = {
      '/doc/createBy': {
          'POST': DocCreator(),
         },
     '/doc/': {
          'GET': DocPresenter()
      },
   .....
  }
  def applyRoute(route, method, requestData):
    logic = config[route][method]
    if logic.isValid(requestData):
      try:
        data = logic.process(requestData)
        serilizedData = logic.serialize(data)
        return Response(serilizedData)
      except Exception:
        return Response(500)
    else:
      Response('Not valid')

Отредактировано vasi.che (Июль 28, 2017 13:49:36)

vasi.che
Что-то как-то все замороченно. Я себе представлял нечто такое:

 class SomeSerializer(serializers.ModelSerializer):
    class Meta:
        model = models.SomeModel
        fields = (
            'id',
            'attribute',
            'oneElseAttribute',       
        )
    oneElseAttribute = serializers.CharField(source='one_else_attribute', validators=[val1, val2])
    def validate(self):
        '''
            Object level validation, must raise ValidationError on failure
        '''
        pass

Вобщем, результаты поиска ответов у зарубежных и отечественных коллег. С мнением FishHook многие согласны. Вот боле-мене развернутый ответ Large web apps in Python: A good architecture. Ответ на вопрос размещения бизнес логики развернут. Не view, ни model не подходят для этого дела, надо выносить в отдельный слой. Похожих мнений достаточно.

vasi.che
Slow довольно развернуто ответил. Со своей стороны добавлю несколько комментариев касательно pure Django vs DRF.

Прежде всего, если используется DRF, то часть джанги, которая связана формами, темплайтами и non-DRF вьюхами, очень часто вообще не используется. Т.е. по сути это немного другой стек - бэкенд реализует REST API, а фронтенд пишется на JavaScript, в то время, как pure Django - это HTML, который генерируется на сервере.
DRF при этом позволяет очень быстро и просто сделать API, при условии если объекты вашего приложения хорошо соответствуют моделям в Django. Чем больше расхождений, тем больше приходится подкручивать в коде, и тем больше сопротивления придется преодолевать.
Что хорошего в DRF - он написан с учетом best practice in REST. Если ваше API соответствует ванильному REST, то написать его будет быстро и легко, если нет, то будет, как в ситуации выше. Но нужно учитывать, что REST сам по себе не является серебряной пулей и обладает рядом недостатков, которые неизбежно наследует DRF, как фреймворк. К примеру, что ванильный REST не позволяет одним запросом вытягивать несколько объектов разного типа, в этом случае лучше смотреть в сторону GraphQL. Либо дилемма тяжелых запросов vs много слишком частных апишек (опять-таки решается GraphQL, либо кастомными сериализаторами, которые будут возвращать только нужные поля, запрошенные в GET параметрах).
Что еще хорошего в DRF - он довольно хорошо сегментирован на абстракции, и переопределить можно практически все, что хочешь (но не ORM). Дополнительно т.к. он использует джангу, то вы бесплатно получается такие плюшки, как админку, возможность наклепать Web странички на темплейтах (если оно вам надо, конечно) и вообще весь джанговский стек.
Что плохого в DRF - он испольует джангу, поэтому он МЕДЛЕННЫЙ, а также обладает другими недостатками джанги (снова ORM) и остальное. Т.е. другими словами - если нужно запилить небольшой проект, то DRF - это довольно круто, а для тяжелого не очень.

Отредактировано ZAN (Авг. 9, 2017 15:47:42)