Я относительно новичок в разработке шаблонов, но я чувствую, что у меня есть хорошее представление о шаблоне MVC и преимуществах, которые дает это разделение кода.
Тем не менее, оба раза я видел шаблон MVC в действии (Magento и Joomla!), Есть дополнительная специализация, с представлением, состоящим как из класса представления (блок Magento), так и файла шаблона PHP. Я был бы признателен, если бы кто-нибудь мог объяснить преимущества этого раскола.
Я также не понимаю, как разделить мой код между классом вида и файлом шаблона. Иногда я нахожу себя автором того, что кажется избыточным классом вида (в Joomla!), Который просто обращается к модели, а затем просто делает данные доступными для шаблона. Какой код должен появиться в шаблоне и какой код должен появиться в классе представления?
Просмотр в шаблонах дизайна, основанных на MVC, отвечает за все ваши логики пользовательского интерфейса. Они должны запрашивать информацию на уровне модели и, исходя из того, что они получают, выбирать, какие шаблоны следует использовать для создания ответа. Или даже если требуется рендеринг (просмотр также может просто отправить HTTP-заголовок).
Можно сказать, что в классических шаблонах MVC и Model2 MVC представление читается только с уровня модели, но контроллер только записывает на него.
Если вы получаете некоторое состояние ошибки на уровне модели, представление принимает основной шаблон макета и дополняет его шаблоном, который содержит фрагмент HTML для сообщений об ошибках. Затем он собирает все, что показывает пользователю (что в случае веб-приложений является браузером).
Шаблоны в вашем основном веб-приложении – это просто простые файлы с сочетанием тегов и переменных php.
Вы можете рассматривать view как то, what и шаблон как how .
Представление готовит данные с использованием модели и делает эти данные доступными для шаблона.
Шаблон, в свою очередь, обычно называется (по крайней мере, в Joomla!) В области представления.
Вначале это может показаться излишним, но сила этого подхода проявляется при использовании переопределений шаблонов . Затем представление можно оставить в покое, и только шаблон (или подшаблоны для этого вопроса) будет переопределен.
Даже используя тот же основной шаблон (Joomla!), Вы можете указать другой шаблон представления в качестве параметра, если вам нужна специализация презентации. Это также исключает повторение кода .
Например, скажем, вы создаете новый основной шаблон . Вы можете переопределить некоторые из стандартных представлений / шаблонов и оставить некоторые другие нетронутыми. Затем вы можете создать новый вид , скажем, просмотр блога , а также 2 шаблона для него, с интервалом между цветами и темными плотными , которые будут использоваться в двух разных сценариях. Таким образом, у вас есть только одна точка зрения, чтобы подготовить все то, what и несколько разных шаблонов, чтобы позаботиться о том, how .
В общем случае разделение между «View» и «Template» заключается в том, что если вы собираетесь представить данные представления с помощью разных методов [т.е. HTML, XML, JSON и т. Д.], Тогда вам не нужно переписывать класс «Вид», создавать только новые классы «Шаблон». Это полезно, если вы хотите включить вызовы AJAX в свой интерфейс или совершать вызовы из других приложений, например приложения для смартфонов.
Прочтите это http://www.codinghorror.com/blog/2008/05/understanding-model-view-controller.html . Для меня MVC означает запись функции в массив и цикл через этот массив и, в конечном итоге, вызов функции в основной программе. Но для многих людей он, кажется, отделяет модель (базу данных) от представления (html-шаблон) и контроллера (основное приложение). Но это не то, что я думаю, особенное в программе. Естественно, когда вы разрабатываете веб-приложение, у вас есть все эти бэкэнды, такие как база данных, браузер, бэкэнд и интерфейс, html, css, файлы изображений, видеофайлы и язык php и т. Д. Почему это сложное слово запутывает разработку? Я считаю, что MVC полезен для общего. Изучите образец декоратора, это намного более полезно.
Честно говоря … лучшим вариантом для производительности является создание веб-сервисов в бэкэнд и использование библиотеки javascript для общения с сервером. joomla и другие дистрибутивы cms пытаются абстрагировать оба эти шаблона проектирования в MVC, вызывая гибрид MVC и веб-сервисов / клиентский код. такой гибридный характер позволяет расширять расширения в javascript-ландшафт, который, по-видимому, является направлением, в котором находится веб-сайт.