2013-06-19 5 views
3

В попытке следовать лучшим методам MVC Я стараюсь, чтобы весь мой код следовал за толстой моделью, точная методология управления, поэтому кто-то мог бросить взгляд на нижнее и сказать мне, если я На правильном пути?CakePHP Модели жира и тощие контроллеры - appModel

В настоящее время в моем приложении у меня есть

ExpenseClaims hasMany Expenses 
Expenses belongsTo ExpenseClaims 

В моих страницах/admin_index.ctp Мне нужно, чтобы сумма всех расходов, относящихся к каждому ExpenseClaim перечисленного.

Таким образом, лучший КФН способом я могу видеть, чтобы сделать это было бы, чтобы загрузить модель ExpenseClaim в AppModel

App::uses('ExpenseClaim', 'Model'); 

И тогда есть функция внутри AppModel, что я могу использовать через контроллеры приложений (потому что его в appModel), что я могу передать идентификатор ExpenseClaim, и он вернет в общей сложности все связанные расходы.

Это правильный способ MVC сделать это, а не делать все это в контроллере?

Заранее спасибо

+0

Ну ... вы используете торт. Это уже означает, что все методы, связанные с MVC, были выброшены. Поскольку CakePHP является клоном Rails, вам следует сосредоточиться на тех практиках, которые рекомендуются для пользователей Rails. Что касается вашего вопроса: ** всегда полезно оставить любое приложение и/или бизнес-логику из «контроллера». ** К сожалению, поскольку Cake делает вид, что модель является экземпляром ActiveRecord, у вас все еще будет много логики приложения в «контроллерах». –

+0

Хм, это не очень полезно. –

+1

Я бы рекомендовал, чтобы все производили модели Fat, а не Fat, потому что модели Fat упрощают изменение бизнес-логики везде, где используется модель. Модели становятся многоразовыми. Напротив, Fat Controllers затрудняет работу, поскольку бизнес-логика заключена в контроллер, и сделанные изменения не используются повторно в других контроллерах. Если в случае, если вы не можете уменьшить контроллер, вам нужно разделить бизнес-логику более чем на одно действие, а не реализовать его в одном действии. Это облегчит нашу жизнь. –

ответ

8

Лучший КФН путь является, как вы говорите, написать функцию в модели. Но !! Не делайте этого в AppModel, это плохая практика. Почему бы вам поместить код, связанный с двумя (не более) моделями в AppModel? Каждая модель наследует эту функцию, что не имеет большого смысла. Предположим, у вас есть «модель меню» или «модель пользователя», нелогично, что они наследуют функцию totalExpenses, верно? Я понимаю, что вы хотите, чтобы функция была доступна на каждом контроллере и просматривалась, если необходимость возрастает, но это не способ сделать это.

Шаг за шагом (на самом деле, всего два шага):

1) В модели ExpenseClaim, написать новую функцию, которая будет вычислять сумму расходов

class ExpenseClaim extends AppModel { 
     /* definitions and validations here*/ 

     public function totalExpenses($id) { 
      return $this->Expenses->find('count', array('conditions'=> 
                array('expense_claim_id' => $id))); 
     } 
} 

Итак, в вас ExpenseClaimsController может вызвать эту функцию с

$total = $this->ExpenseClaims->totalExpenses($the_id); 

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

ClassRegistry::init("ExpenseClaims")->totalExpenses($the_id); 

или

$this->loadModel("ExpenseClaims"); 
$this->ExpenseClaims->totalExpenses($the_id); 

(как в контроллере), и вы будете иметь то значение доступного, не подвергая эту функцию в AppModel.

(Btw, код, который я написал, должен работать, но вам нужно точно настроить имена контроллеров и моделей или закрыть круглые скобки здесь и там, я его не тестировал).

Теперь, это общая передовая практика. Работает в большинстве случаев с более сложными функциями.Но для вашего случая в конкретном случае вы можете взглянуть на counterCache cake, он держит подсчет вещей без необходимости многого.

+1

Спасибо за очень хорошо написанный и простой ответ! –

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