Это плохая практика для представлений, чтобы создавать частичные (дочерние) представления?

Question

Я создаю небольшую структуру представления. Я не пытаюсь придерживаться строгой приверженности MVC, но я определенно пытаюсь не мешать практикам MVC.

В любом случае, один из моих вопросов таков: плохо ли для представления создавать собственные дочерние представления?

Например, в псевдо-коде C #:

/*BlogEntryView*/
<h1>my blog entry...</h1>
<div class="Comments">
{# //code
  foreach(var comment in Comments){
    Write(new CommentView(comment));
  }
#}
</div>

Это плохая практика для стиля MVC? Правильно ли будет сделать «заполнитель» в BlogEntryView, где модель заполняет его CommentViews?

(также, пожалуйста, не помечайте asp.net-mvc, это похоже, но ни в коем случае не использует технологии ASP.Net MVC)

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

/*BlogEntryView*/
<h1>my blog entry...</h1>
<div class="Comments">
{# SomePlaceholder #}
</div>

/*In the model code for BlogEntry*/
//v is a BlogEntryView
foreach(var comment in Comments){
  v.PlaceHolder.Add(new CommentView(comment));
}

Answer 1

В традиционном MVC есть один вид для каждого контроллера и модели, который называется «Триада MVC».Я думаю, что вы, каков шаблон представления, чтобы иметь возможность встраивать другие шаблоны для повторного использования (например, частичные).

Одна часть технологии, которая делает это правильным с усами .Он использует модель представления в сочетании с шаблоном.Шаблон может запрашивать другие частичные элементы для повторного использования фрагментов других шаблонов.

Проблема многих веб-сред MVC состоит в том, что они обрабатывают представление как шаблон, что является неправильным способом его просмотра (без каламбура).Когда у вас есть класс, представляющий представление, все это становится намного проще.

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

Answer 2

Нет. Именно так работают функции шаблонов ASP.NET MVC в MVC. Тем не менее, потенциальным подводным камнем в ASP.NET MVC является небольшое снижение производительности при поиске в файловой структуре для представлений. Этого можно избежать, явно указав полный путь просмотра.

http://vishalswami.blogspot.com/2007/11/design-patterns-in-mvc_30.html обсуждает архитектуру MVC. Банда четырех также советует, что одним из величайших преимуществ MVC является то, что он облегчает составной пользовательский интерфейс (который вы описываете).

Answer 3

Как ASP.NET MVC, так и Ruby on Rails облегчают подход, который, я думаю, вы ссылаетесь через использование частичных представлений.

Использование вашего примера обычно приводит к представлению, которое вызывает частичное для записи комментария. В ASP.NET MVC C # это будет выглядеть следующим образом: -

<h1>my blog entry...</h1>
<div class="Comments">
  <% foreach (var comment in Model.Comments) { %>
    <% Html.RenderPartial("Comment", comment); %>
  <% } %>
</div>

Следуя современной философии MVC и принципам проектирования, этот вид декомпозиции на небольшие «атомарные» части кода представления активно поощряется во многих кругах. Однако всегда существует баланс между этим разложением и ремонтопригодностью.

Answer 4

Я понимаю, что существуют сообщества как за, так и против представлений, отображающих дочерние представления.

Лично я считаю, что использование RenderPartial все еще вызывает озабоченность.У меня нет проблемы с представлением, зависящим от другого представления, при условии, что оно предполагает ту же модель, которая предлагается моделью действия контроллера.

С другой стороны, RenderAction не так важен для представления, поскольку он вызывает вызовдействие контроллера, которое затем визуализирует представление.Это полный жизненный цикл запроса.Тем не менее, он имеет много преимуществ, особенно для сквозных задач, таких как навигация по сайту, состояние учетной записи пользователя, реклама или другие функции страницы, которые полностью независимы от основной цели страницы.

Answer 5

Разве плохо для представления создавать свои собственные дочерние представления?Мой ответ "НЕТ".Частичное создание граней дает вам больше возможностей для изменения содержимого пользовательского интерфейса модульным способом.

Всегда есть несколько способов достижения результатов.Я лично считаю, что файлы ascx являются хорошим чистым способом создания модулей многократного использования, которые могут наследоваться от пользовательских элементов управления.Его модульный подход позволяет мне быть очень организованным.

Только мои 2 цента ...