2012-04-16 4 views
3

У меня есть некоторые проблемы с получением хорошей структуры папок в моем проекте, и я хотел бы знать, какие другие способы я могу использовать для структурирования моих файлов.как структурировать модели MVC и модели ORM

В настоящее время я работаю в папке с MVC sturctured.

www/ 
    Controllers/ 
    Models/ 
    Views/ 

Ничего особенного пока. Но я также использую систему ORM. С его помощью я могу легко получить «объект» из моей базы данных, как:

ORM::load('table'); 

Теперь это своего рода код должен находиться в правильной модели? Поэтому я бы получил что-то вроде этого:

<?php 
class userModel 
{ 
    public function getAllUsers () 
    { 
     return ORM::load('table'); 
    } 

    public function getUserById ($id) 
    { 
     return ORM::load('table', 'userid=?', array($id)); 
    } 
} 
?> 

Выглядит хорошо пока, на мой взгляд ... Но есть еще одна вещь. Я также могу указать «модель» при использовании системы ORM. С помощью этой модели я могу в основном настроить правила проверки. Как так:

ORM::withModel('authModel'); 

Это позволяет ОРМ знать, что, прежде чем он добавляет новую строку (или обновляет существующий) в БД, что он должен проверить следующую модель первого для правил проверки.

<?php 
class authModel //Or maybe authValidation?? 
{ 
    // Method gets automatically triggered when an update is done with the ORM 
    public function onUpdate ($obj) 
    { 
     if ($obj->username == '') 
      throw new \Exception('No username'); 
    } 

    public function onInsert ($obj) 
    { 
     // Validations here too. 
    } 
} 
?> 

Теперь проблема в том, что у меня есть 2 вида моделей. Один, где я в основном использую getters/seters для получения и хранения данных в базе данных (от моего контроллера до моей модели).

И у меня есть другая модель, в которой установлены правила проверки ... Я не хочу смешивать их в одной папке. Поэтому я должен придумать для этого еще одну структуру. Что-то вроде:

www/ 
    Controllers/ 
    Models/ 
    Repositories/ 
    Entities/ 
    Views/ 

Это просто, что моя модель не является реальным «хранилище», так как он не хранит какие-либо объектов в классе репо и не имеет методы фиксации() или что-нибудь подобное ,

Я также не могу хранить 2-ую модель (для валидаций) в папке Entities, потому что они не Сущности на всех ...

Любая идея, как я должен структурировать это .. ??

+0

Почему бы вам не использовать некоторые готовы пойти farmeworks с ОРМ как Кохана? –

+6

@webbandit Потому что я создаю свою собственную «инфраструктуру», чтобы получить больше опыта. Я знаю, что могу легко использовать другие фреймворки. Но я тоже хотел бы научиться этому, делая это сам. – Vivendi

ответ

10

Первое, что вы должны понимать, это то, что Модель в MVC не является классом/объектом. Это слой, сделанный из множества объектов. Мне слишком ленится сделать то же самое song'n'dance, так что просто прочитайте this comment (перейдите к разделу «Боковые заметки»).

Корень вашего замешательства заключается в том, что вы признаете две разные обязанности в группе классов, которые вы называете «моделями». У вас на самом деле есть экземпляры классов, ответственные за бизнес-логику (например, ваш класс UserModel) и отдельную вещь под названием ORM, которая загружает и сохраняет контент. И у вас есть аутентификация, которая не подходит ни в одной из групп.

Я хотел бы пойти со структурой, как это:

/application 
    /modules 
     /public 
      /controllers 
      /templates 
     /admin 
      /controllers 
      /templates 
     .... 
    /views 
    /model 
     /logic 
     /persistence 
     /services 
/framework 

Вы можете заметить, что существует отдельная папка /views в /application, а также каждый модуль имеет отдельный /templates.Это связано с тем, что в правильном MVC представления являются экземплярами классов, ответственными за логику представления и обычно жонглируют несколькими шаблонами. Если они хорошо написаны, они также являются многоразовой структурой.

И последнее примечание: не пытайтесь использовать ОРМ. Создайте datamapper для каждого объекта домена, который требует его. Некоторые считают ORMs to be antipatterns. Кроме того, избегайте статических вызовов .. это не код OO. Вы могли бы выиграть от изучения dependency injection

.. мои 2 цента

+0

Хотя я должен не согласиться с тем, что ORM действительно является анти-шаблоном (некоторые говорят о том, что образ репо, например). Я не думаю, что это плохо. Я все равно буду использовать его. Но это еще одно обсуждение. Но вы подробно рассказали мне о структурной части :-) – Vivendi

+1

@Vivendi, я просто надеюсь, что вы прочитали статью об ORM, а не просто расценили ее как нечто, с чем вы не согласны, в принципе. –

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