3

У меня есть две таблицы: Кампании, Кампания_статистика. Мне нужно вывести список кампаний с вложенной статистикой.Хорошая практика использования геттеров в представлении?

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

array(
    'id', // integer 
    'campaign_name',// string 
    'stats'// nested array of arrays with stats by periods 
); 

В целях я имел два Foreach петли (один вложенный внутри другого):

<? foreach ($this->campaigns as $campaign): ?> 
    <div class="campaign"> 
     <?= $campaign['name'] ?> 
     <? foreach($campaign['stats'] as $monthStats): ?> 
      <div class="statistics"> 
       <?= $monthStats['views'] ?> 
      </div> 
     <? endforeach ?> 
    </div> 
<? endforeach ?> 

Эта реализация модели приводит к беспорядочному коду, поэтому я решил попробовать сделать Кампанию объектом. В целях использования я использую геттеры:

<? foreach($this->campaigns as $campaign): ?> 
    <div class="campaign"> 
    <?= $campaign->getName() ?> 
    <? foreach($campaign->getMonthStats() as $monthStats): ?> 
     <div class="statistics"> 
      <?= $monthStats->getViews() ?> 
     </div> 
    <? endforeach ?> 
    </div> 
<? endforeach ?> 

Я никогда не видел, чтобы какой-либо фреймворк использовал такие геттеры. Каковы плюсы и минусы такого подхода?

ответ

4

Красота с геттерами в объектно-ориентированном дизайне заключается в том, что они скрывают сложность вычисления полученного результата. Таким образом, вы можете изменить способ вычисления представлений и его автоматическое обновление во всех приложениях.

Пуристы утверждают, что вы не должны иметь вызовы методов в представлениях и т. Д., Но прагматики, как я, говорят, вызывают вызовы метода в представлениях, поскольку методы могут быть проверены модулем. Однако, когда вы обнаружите, что выходы становятся слишком сложными (Martin Fowler называет эти объекты слишком интимными друг с другом), вам необходимо реорганизовать использование одного вызова метода.

Итог: Методы хорошо, потому что их результаты могут быть проверены

0

Звучит нормально для меня :) Magento позволяет то же самое, например.

В любом случае, это скорее вопрос личного зрения, чем что-либо ... Но я склонен согласиться с вами, это упрощает чтение модели или контроллера (нет необходимости в $ view-> toto = $ model-> getToto()

1

У меня были такие же аргументы с моими коллегами ранее, и я не согласен с использованием методов внутри шаблона. Это делает шаблоны не прозрачными, нет четкого представления о том, что доступно внутри шаблона - вы должны знать объекты, разработчики и разработчики, а также разработчики, которые присоединятся позже, не должны беспокоиться об этом, они должны увидеть, что происходит с передачей в контроллере, и это не так. Не говоря уже о том, что вызовы методов изнутри шаблона могут изменять данные, которые уже были переданы внутри. И хотя я знаю, что в некоторых случаях это нормально для шаблона, чтобы иметь изменения s в цикле или что-то еще, я склонен думать, что шаблон более статичен, а остальная часть кода - итерация по массиву не изменит никакого другого массива. Но я не уверен в объектах.

Он также добавляет дополнительную зависимость для рефакторинга.

И это также добавляет сложности и обольщения для разработчиков, чтобы начать вызывать SQL или делать тяжелую логику внутри шаблона.

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

+0

Мы говорим о добытчиках, а не большие методы :) Я согласен с вами что-нибудь более сложным, чем добытчиками – haltabush

+1

права. хорошо, я просто боюсь двоеточий: D Я полагаю, если вы знаете, что делаете, его нормально вмешиваться в уран. –

1

Как правило, вы не увидите явно получателей, вы увидите, что люди получают доступ к свойствам.
Однако это будет работать только в том случае, если вы являетесь публичным.
Реализация Zend_Form в представлении позволяет получить доступ к элементам и другим атрибутам с помощью геттеров и сеттеров.
Я не вижу серьезных проблем с выбором, который вы сделали.
Однако я, возможно, внедрил второй foreach() с помощью вспомогательного помощника partialLoop() или, возможно, создал свой собственный помощник вида, особенно если это было то, что я намеревался использовать в более чем одном месте.

//example of what is commonly seen... 
<? foreach($this->campaigns as $campaign): ?> 
    <div class="campaign"> 
    <?= $campaign->name ?> 
    <? foreach($campaign->stats as $monthStats): ?> 
     <div class="statistics"> 
      <?= $monthStats->views() ?> 
     </div> 
    <? endforeach ?> 
    </div> 
<? endforeach ?> 

Просто моё мнение, получайте удовольствие.

Смежные вопросы