Зачем разбивать представление в MVC на класс представления и шаблон

Я относительно новичок в разработке шаблонов, но я чувствую, что у меня есть хорошее представление о шаблоне MVC и преимуществах, которые это разделение кода приносит.

Однако оба раза я видел шаблон MVC в действии (Magento и Joomla!), есть дополнительная специализация, с представлением, состоящим как из класса представления (блок Magento), так и файла шаблона PHP. Я был бы признателен, если бы кто-нибудь мог объяснить преимущества этого раскола.

Я тоже не понимаю, как разделить мой код между классом вида и файлом шаблона. Иногда я нахожу себя автором того, что кажется избыточным классом вида (в Joomla!), Который просто обращается к модели, а затем просто делает данные доступными для шаблона. Какой код должен появиться в шаблоне и какой код должен появиться в классе представления?

Ответ 1

Просмотр в шаблонах дизайна, основанных на MVC, отвечает за все ваши логики пользовательского интерфейса. Они должны запрашивать информацию на уровне модели и, исходя из того, что они получают, выбирать, какие шаблоны следует использовать для создания ответа. Или даже если требуется какой-либо рендеринг (просмотр может также просто отправить HTTP-заголовок).

_{Можно сказать, что в классических шаблонах MVC и Model2 MVC представление читает только с уровня модели, но только контроллер записывает на него.}

Если вы получаете некоторое состояние ошибки на уровне модели, представление принимает основной шаблон макета и дополняет его шаблоном, который содержит фрагмент HTML для сообщений об ошибках. Затем он собирает все показания пользователю (что в случае веб-приложений является браузером).

Шаблоны в вашем основном веб-приложении - это просто простые файлы с сочетанием тегов и переменных php.

Ответ 2

Вы можете рассматривать view как what и шаблон как how.

Представление готовит данные с использованием модели и делает эти данные доступными для шаблона.

Шаблон, в свою очередь, обычно вызывается (по крайней мере, в Joomla!) в области видимости.

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

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

Например, скажем, вы создаете новый основной шаблон. Вы можете переопределить некоторые из стандартных представлений/шаблонов и оставить некоторые другие нетронутыми. Затем вы можете создать новый вид, скажем, просмотр блога, а также 2 шаблона для него, с интервалом между цветами и темными плотными, которые будут использоваться в двух разных сценариях. Таким образом, у вас есть только один вид, чтобы подготовить все what и несколько разных шаблонов, чтобы позаботиться о how.

Ответ 3

В общем случае разделение между "View" и "Template" заключается в том, что если вы собираетесь представить данные представления с помощью разных методов [т.е. HTML, XML, JSON и т.д.], Тогда вам не нужно переписывать класс "Вид", создавать только новые классы "Шаблон". Это полезно, если вы хотите включить вызовы AJAX в свой интерфейс или совершать вызовы из других приложений, например приложения для смартфонов.

Ответ 4

Прочитайте это http://www.codinghorror.com/blog/2008/05/understanding-model-view-controller.html. Для меня MVC означает запись функции в массив и цикл через этот массив и, в конечном итоге, вызов функции в основной программе. Но для многих людей он, кажется, отделяет модель (базу данных) от представления (html-шаблон) и контроллера (основное приложение). Но это не то, что я считаю особенным в программе. Естественно, когда вы разрабатываете веб-приложение, у вас есть все эти бэкэнды, такие как база данных, браузер, бэкэнд и интерфейс, html, css, файлы изображений, видеофайлы и язык php и т.д. Почему это сложное слово запутывает разработку? Я считаю, что MVC полезен для общего. Изучите образец декоратора, который намного полезнее.

Ответ 5

Чтобы быть честным... лучшим вариантом для производительности является создание веб-сервисов в бэкэнд и использование библиотеки javascript для общения с сервером. joomla и другие дистрибутивы cms пытаются абстрагировать оба эти шаблона проектирования в MVC, вызывая гибрид MVC и веб-сервисов/клиентский код. такой гибридный характер позволяет расширять расширения в javascript-ландшафт, который, по-видимому, является направлением, в котором находится веб-сайт.