2016-05-19 4 views
2

В настоящее время, секция обслуживания уровневой модели держит MainService со следующими целямиИспользование представлений и шаблонов

MainService => Communicates with persistence layer, 
       does the UI logic, 
       renders the respective view 

ОП из the question here описывает идею; представления должны делать пользовательский интерфейс, а затем визуализировать (зависит) соответствующий шаблон.

Пример MainService подобен

echo $this->factory->template() 
    ->file('/path/to/template') 
    ->set('url', 'some/url') 
    ->render(); 

Очевидно, что это явно противоречит концепции Views. И здесь я смущаюсь - текущая реализация сервиса очень похожа на представление. Это точка зрения?

+0

Это определение кажется использовать «сервис» за то, что я хотел бы рассмотреть контроллер. Если вы посмотрите, как некоторые крупные «mvc» фреймворки (symfony, laravel) реализовали mvc, то вы направляете запрос на контроллер, который берет вход пользователя и делает все, что он должен делать с ним, предпочтительно используя службы. А затем визуализируйте view/template – JimL

+0

Afaik, контроллер в php - это в основном сервис, который является частью слоя модели. – sitilge

+0

В вариантах упоминания «mvc» они используют службы, такие как служба журнала, почтовая служба и т. Д. Обратите внимание, что я постоянно использую «mvc» с кавычками, поскольку это только определенный уровень, который реализуется в этом шаблоне. Кажется, он не установлен в камне и часто несколько самоуверен, как реализуются эти (и другие) шаблоны. если вы заинтересованы в обсуждении структуры/шаблона, я предлагаю вам опубликовать по адресу http://codereview.stackexchange.com/ – JimL

ответ

-1

Контроллер отвечает за:

  • чтение входных данных пользователя

  • запроса данных от модели

  • вызова View с этими данными

Типовом несет ответственность за:

  • извлечения данных из слоя сохранения

  • обработка данных в соответствии с запросом контроллера

The View отвечает за:

  • рендеринга шаблона с данными предоставляемый контроллером и показывающий его пользователю

В вашем примере для MainService правильно поддерживать связь с уровнем сохранения. Но выполнение логики пользовательского интерфейса и визуализация представления (шаблона) - это работа для представления.

Если вы используете фреймворк, такой как Laravel, Zend, Angular2, вы никогда не увидите слой «Вид». Вы определяете шаблон, но структура выполняет рендеринг на основе данных, которые вы предоставляете в контроллере.

Пример потока с Laravel для отображения страницы профиля пользователя:

  • Laravel будет вызывать действие контроллера, основываясь на настройках маршрута (определенный URL для определенного контроллера и действия)

  • контроллер будет читать параметр (идентификатор пользователя)

  • контроллер будет запрашивать у UserService пользователь с этим идентификатором

  • служба будет делать запрос к базе данных и построить модель пользователя (объект), который будет возвращать к контроллеру

  • Контроллер будет вызывать View с идентификатором шаблона и массив данных, полученных от объекта пользователя

  • The View будет оказывать шаблон с данными из массива

+0

То, что вы описали, не MVC. Это еще одна ужасная Rails-подобная структура. –

+0

Вы можете поделиться своей точкой зрения о том, что такое MVC –

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