2015-10-14 3 views
1

Я строю простую структуру MVC и застреваю в том, как я создал объекты.Инициализация объектов на PHP MVC - перед представлением или во время

TL; DR: Лучше ли инициализировать объекты перед видом или во время рендеринга?

Пример:

КОНТРОЛЛЕР

<?php 
class Controller { 
    public function __construct() { 
     $user = new User(); 
    } 
} 
?> 

ОБЪЕКТ ПОЛЬЗОВАТЕЛЯ

<?php 
class User { 
    public function __construct() { 
     $this->setFriends($arg); 
    } 
    public function setFriends($arg) {} 
    public function getFriends() {} 
} 
?> 

ОБЪЕКТ ДРУГ

<?php 
class Friend { 
    .. properties .. 
    .. methods() .. 
} 
?> 

VIEW

<?php 
foreach($user->getFriends() as $friend){ 
    .. $friend is a Friend Object already .. 
    .. html... 
} 
?> 

Вопрос: Лучше инициализировать Friend объект на методе setFriends (до точки зрения нагрузки - помните, что есть много друзей) или по методу GetFriends (на виду нагрузки)?

public function setFriends($arg) { 
    foreach($arg as $item) 
     $this->friends[] = new Friend($item) 
} 

ИЛИ

public function getFriends() { 
    $tmp = array(); 
    foreach($this->friends as &friend) 
     $tmp[] = new Friend($friend) 
    return $tmp; 
} 

Я думаю, что в первом случае, память будет предварительно потребляется. И второй случай, объект Friend будет инициализироваться, только если вызов view getFriends.

+0

Это не похоже ни на одну, ни на другую ситуацию. Если вам даны новые данные, вам нужно вызвать setFriends, который назначает новые объекты. Что такое '$ this-> friends' и почему вы создаете временный массив объектов Friend для возврата? Нам нужна дополнительная информация об использовании кода. Каков ожидаемый вариант использования вызова get/set? Сколько раз они называются? и т. д. В ООП обычно объекты создаются после того, как у вас есть данные для их инициализации. –

+0

Общее предложение этой реализации состоит в том, чтобы перейти к представлению (в foreach) инициализированному объекту (я хочу разобрать представление из функций модели/контроллера/новых объектов, подумайте, как другой человек, создающий представление .. он не нужно инициализировать объект friend (уже передан) ... Я не знаю, был ли я понятен (извините мой английский) – brnmonteiro

+0

Тогда представление не является хорошим местом для любой из ваших функций get/set. Они принадлежат контроллеру , таким образом отделяя представление от создания объектов Friend вместе. Обратите внимание, что getFriends должен возвращать '$ this-> friends' и избегать копирования всех вместе. Он все равно будет копией, если вы не измените функцию на' & getFriends() ' –

ответ

1

Как общее правило:

Все, что требуется, чтобы сделать должно требоваться при каждой загрузке страницы повсеместно на ранней инициализации (обычно в boostrap слое или аналогичный). Это включает в себя такие вещи, как базовый контроллер (из которого другие расширяются), базовый вид (то же самое здесь), объект обработчика базы данных и т. Д.

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

В этих случаях всегда лучше перемещать как можно больше бизнес-логики из своих представлений, а также сохранять свой PHP в представлениях для простых вещей, таких как циклы и эхо. В структурах MVC вы часто видите массивы, созданные в контроллере, так что многие данные, которые уже были финализированы, могут быть переданы в представление. Например, в вашем контроллере вы можете создать экземпляр своего пользователя для передачи в представление в качестве аргумента, а затем также создать экземпляр своих друзей и добавить их в массив друзей, который вы передадите в качестве другого аргумента. Или объедините эти два массива в один большой массив и передайте один параметр «parameters» в представление. Это было бы стандартным параметром, который могли бы разделять все ваши представления, а затем выделяя массив данных в самом представлении.

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

Однако в определенных обстоятельствах вам могут понадобиться только друзья, поэтому имеет смысл создавать их, когда они вам понадобятся, вместо того, чтобы всегда иметь их, даже если вы этого не делаете. Если это так, ваш пользователь должен по крайней мере иметь поиск своих друзей и иметь возможность установить свойство в себе, которое будет содержать информацию, необходимую для поиска друга. Это означает, что независимо от того, включен ли он в ваш пользовательский конструктор (если вам всегда нужно знать, какие друзья у пользователя) или в отдельной функции, например getFriends (если вы только иногда должны знать о друзьях пользователя), вы будете должен иметь по крайней мере идентификатор каждого друга, который может быть сохранен как свойство вашего пользователя, поэтому вы можете позже пропустить его и создать экземпляр друзей на основе идентификатора.

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

Я знаю, о чем много думать, но я надеюсь, что это поможет!

+0

Спасибо, очень помогите! – brnmonteiro

+0

Рад, что это помогло! Примите ответ, если он решит вашу проблему. – carbide20

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