Чтобы получить данные Google Analytics и показать на странице, какие элементы наиболее популярны, должен ли код принадлежать модели, контроллеру или представлению?

Question

Предположим, что есть вызов для получения данных Analytics от третьей стороны или через наш кеш-данные на сервере для «самых популярных элементов», и мы показываем названия этих элементов на всех наших страницах, если мы поместим этокод в компоненте Model, Controller или View (Helper)?

Может быть, это не совсем Model, потому что его нет в нашем хранилище данных.

Может быть, это Controller ...быть в "общем контроллере", например в app/controller/application.rb, чтобы быть доступным во всех видах?Что если он получен в коде контроллера, но через 1 месяц другой человек последует новой спецификации и уберет ее отображение в представлении, тогда код, вероятно, останется в контроллере, и никто не удалит его.

Если это в помощнике ... то, что если в другой части кода, контроллер должен получить эти данные и сохранить их в @popular?Кроме того, разве помощники не должны помогать отображать данные, помещая повторяющиеся задачи в методы?Так что помощники не должны делать так много логики выборки данных.

Где наиболее правильно размещен код?

Answer 1

(Отказ от ответственности: это исходит из опыта Django, приношу свои извинения, если термины или методология напрямую не переводятся в используемую вами среду MVC.)

Мой процесс проектирования в основном будет выглядеть так:следующим образом:

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

Поэтому я бы настроил модель для обработки хранения подмножества данных Google Analytics для поставленной задачи, сохраняя «самые популярные элементы» в вашем случае.Затем я создал бы автоматизированное задание (скажем, в cron или в Django, я бы использовал Celery), чтобы собирать эти данные на регулярной основе, возможно, в полночь каждую ночь.

Затем я просто написал бы несколько помощников, чтобы быстрозапросите эти агрегированные данные и отобразите их в моем шаблоне (представление в других средах).

В итоге я бы использовал комбинацию модели и представления в парадигме MVC.Я не вижу смысла вовлекать Контроллера в этот процесс.

Answer 2

Я хотел бы предложить создать источник данных google_api.Быстрый поиск в Google должен вызвать несколько из них, которые кажутся наполовину законченными, чтобы начать.

Используйте класс GAPI из кода Google из источника данных, чтобы получить данные из Google и отформатировать результаты в то, что выможно использовать.

Затем вы можете настроить модель для каждой метрики, которую вы хотите отслеживать.IE.класс GoogleAnalyticsKeyword, GoogleAnalyticsAdWordCampaign и т. д. Эти модели могут быть настроены для использования вашего пользовательского источника данных.Из модели вы можете выполнять кэширование, проверку и т. Д. Данных.

Затем просто ссылаться на модели в массиве использования в контроллере.Либо app_controller, либо dashboard_controller и т. Д. Затем просто запросите модели у контроллера, для которого вам нужны данные.

http://code.google.com/p/gapi-google-analytics-php-interface/

http://github.com/msadouni/cakephp-plugin-google-analytics

Answer 3

Хотя я использую .net mvc, я думаю, что могут применяться те же принципы.

То, что я здесь говорю, это то, что я обычно имею:

Контроллер> Сервис> Код репозитория.

Так что в этом случае у вас будет служба аналитики, которая обрабатывает запроси может делать вызовы третьей стороне или может вызывать уровень хранилища (возможно, оба), который извлекает данные из базы данных.Но так все звонки проходят через один и тот же сервис.Плюс удаляет любые знания о том, как данные извлекаются.Фактически однажды у меня была похожая ситуация, когда мы использовали почтовый клиент и извлекали некоторые аналитические данные со своего сервера, а некоторые из нашей базы данных.Все это было скрыто в слое обслуживания, поэтому все, что было возвращено, было моделью, которую можно было использовать, однако она была сочтена подходящей.

Тогда все контроллеры, которым это необходимо, могут делиться.В представлении у меня тогда был бы помощник, который отображает эти данные.Опять же, любой желающий может вызвать помощника и передать данные модели, необходимые для этого помощника.Это позволяет вам применять принцип СУХОЙ.

Опять же, это работает для меня.YMMV

Answer 4

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

Я не думаю, что это должно быть в вашем хранилище данных, чтобы считаться моделью.

Мои 2 цента.