Где я должен поместить описание выходного поля, контроллер или модель?

Question

Я заметил, что у меня есть один и тот же кусок кода, расположенный на верху нескольких моих контроллеров.Они имеют тенденцию выглядеть следующим образом:

def app_description(app):
    """ Dictionary describing an app. """
    return {'name': app.app,
            'id': app.id,
            'is_new': app.is_new(),
            'created_on': app.created_on.strftime("%m/%d/%Y"),
            'configured': app.configured }

Я назову это из пары разных действий в контроллере, но обычно не за пределами этого контроллера.Доступ к свойствам.Это вызывает методы.Он форматирует непрозрачные объекты (например, даты).

Мой вопрос: это код контроллера или код модели?

Случай для контроллера:

• Он определяет мой API.
• В настоящее время он используется только в этом модуле.
• Кажется, здесь нет никакой логики.

Случай для модели:

• Похоже на описание данных, за которые должна отвечать модель.
• Такое ощущение, что я мог бы захотеть использовать это в других контроллерах.Еще не получил, но эти функции все еще довольно новые, так что они могли бы.
• Присоединение функции к объекту, которому она явно принадлежит, кажется лучше, чем оставлять ее как функцию уровня модуля.
• Это может быть более кратко определено на модели.Что-то вроде того, что объект модели верхнего уровня определяет .description(), а подклассы просто определяют черный / белый список свойств, плюс переопределяют сам метод для вызова функций.Я почти уверен, что было бы меньше строк кода (поскольку это спасло бы меня от повторения таких вещей, как 'name': app.name), что кажется хорошей вещью.

Answer 1

Ответ, который я окончательно определил:

В краткосрочной перспективе использование этих методов в контроллерах - это нормально.Если они определяют выход, тогда, ОК, они могут остаться там.Они используются только в модели.

Есть пара вещей, на которые стоит обратить внимание, которые указывают на то, что они выросли, и должны пойти в другое место:

• В одном случаеМне нужен был доступ к канонической сериализации объекта.В этот момент он перешел в модель как метод модели.
• В другом случае я обнаружил, что форматировал все метки времени одинаково.У меня есть стандартный @ajaxify декоратор, который выполняет такие вещи, как установка Content-Type заголовков, кодирование JSON и т. Д. В этом случае я переместил туда стандартное форматирование даты и времени - когда кодировщик JSON достигнет даты и времени (ранее не сериализуемых)это всегда относится к нему (секунды для меня).
• В третьем случае я понял, что повторно использую эту функцию в паре контроллеров.Для этого я вытащил его в общий класс (как предложил другой ответ) и использовал его для определения своего «веб-API».Я использовал этот шаблон раньше - это имеет смысл для группировки аналогично используемых данных (таких как данные временных рядов или списки топ-N).

Я подозреваю, что есть еще что-то, но в основном я не думаю, что там все так похоже, как я думал, что они были изначально.В настоящее время я рад думать о них как о соглашении для простых объектов в нашей кодовой базе (small-ish, new-ish), с пониманием того, что после нескольких итераций может появиться лучшее решение.Тем временем они остаются в контроллере и определяют мой интерфейс только для AJAXy-JSON.

Answer 2

Не уверен, какой фреймворк вы используете, но я бы предложил создать эту вспомогательную функциональность в своем собственном классе и поместить ее в общую папку, такую ​​как lib /

В качестве альтернативы вы могли бы иметь вспомогательный модуль приложения, в котором просто есть набор этих полезных функций всего приложения.

В любом случае, я бы держал его подальше от модели и контроллера.