MVC и ORM - какая логика модели куда идет? - PullRequest
Новая
       18

MVC и ORM - какая логика модели куда идет?

0 голосов
/ 14 октября 2011

Для ясности рассмотрим довольно стандартный функционал «Регистрация пользователя»:

Мой ORM (Propel) позволяет вам изменить класс ormUser , который расширяет ormUserBase , чтобы ввести пользовательские функции.

Теперь, когда я связал Propel с платформой MVC, мне интересно, какая логика должна идти куда с точки зрения наилучшей практики.

Для моей функции регистрации пользователей я бы создал:

  • RegistrationController - , который использует

  • UserModel - , который в свою очередь должен вызывать что-то вроде

  • LoginView
  • LogoutView
  • SignupView
  • ProfileView

Таблица базы данных user связана с user-profile , и Propel создал удобные методы для работы с этими таблицами. Но теперь стандартных методов Propel недостаточно, и мне нужно расширить функциональность.

Где можно было бы сделать это правильно?

Буду ли я расширять ormUser для новых методов запросов и помещать логику без запросов в мою UserModel ? Или вы просто проигнорируете ormUser и будете использовать UserModel для всего пользовательского, вызывая другие ormTableNameClass -s там, где это необходимо для моей логики?

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

ОБНОВЛЕНИЕ: Использование классов ORM непосредственно из контроллера в MVC, плохая практика? показывает, как обычно работает с Propel, который, на мой взгляд, перекрывает модель фреймворка ...

1 Ответ

0 голосов
/ 16 октября 2011

Я пришел к этому из-за того, что Propel соединял Symfony 1.0 в течение нескольких лет. Возможно, я не полностью понял ваш пост, но я не уверен, чего, по вашему мнению, не хватает в Propel.

Для ясности, то, что вы называете моделью, я бы назвал "бизнес-логикой" или "действием". Модель, по крайней мере, как я понимаю жаргон, - это база данных и слой классов поверх базы данных. Ваши «взгляды» по-прежнему являются частью IMO в разделе логики / действий в MVC. Я бы рассматривал представление как официально ссылающееся на что-то другое: выходной слой, который отображает результат действия.

В Propel у вас есть три класса для каждой таблицы: строка, одноранговый узел и запрос (исторически пользователи Propel привыкли к двум, поскольку запрос является новым). Строка проста - просто представление класса строки базы данных. Пир предназначен для операций в масштабе всей таблицы, таких как выбор нескольких строк, а класс запросов - это новый цепочечный API для выполнения операторов в базе данных.

Итак, в каждом из ваших действий (вход в систему, выход из системы и т. Д.) Вы должны вызывать Propel для выполнения необходимой работы. Если вы обнаружите, что в вашем действии имеется большой кусок кода, в большинстве случаев он может быть реорганизован в строку или узел Propel. Это согласуется с эмпирическим правилом MVC «тонкие контроллеры, толстые модели», т. Е. Постарайтесь сохранить тонкие данные в контроллере.

Как вы должны структурировать свой проект, зависит от вашей структуры, но я бы показал это так: 

    RegistrationController - which uses the

    UserAction - which in turn should call something like

    LoginAction (rendered by LoginView)
    LogoutAction (rendered by LogoutView)
    SignupAction (rendered by SignupView)
    ProfileAction (rendered by ProfileView)

    - each of which access the model UserModel
...