Это хорошая практика, чтобы использовать геттеры в представлении? - PullRequest
Новая
       34

Это хорошая практика, чтобы использовать геттеры в представлении?

3 голосов
/ 25 марта 2012

У меня есть две таблицы: Campaigns, Campaign_statistics. Мне нужно вывести список кампаний с вложенной статистикой.

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

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 ?>

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

* * 1010

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

Ответы [ 4 ]

4 голосов
/ 25 марта 2012

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

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

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

1 голос
/ 25 марта 2012

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

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

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

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

1 голос
/ 25 марта 2012

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

Только мое мнение, веселись.

0 голосов
/ 25 марта 2012

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

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

...