Asp.Net MVC: серверные элементы управления против класса HTML для отображения элементов управления?

Question

Каковы преимущества рендеринга элемента управления следующим образом:

<% Html.RenderPartial("MyControl") %> or
<%=Html.TextBox("txtName", Model.Name) %>

через Интернет Стиль форм:

<uc1:MyControl ID=MyControl runat=server />

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

Если это не поощряется, то как вы можете справиться с этими сценариями:

• Вам необходимо сделать элемент управления видимым условно, и вы не хотите заполнять свой HTML логикой рендеринга.

• У вас есть <input type="text" value="<%= Model.Name %>" />, но вам нужно проверить, является ли модель нулевой, потому что в противном случае возникнет исключение NullPointerException.

[EDIT] Я спрашивал об этом, когда начинал с ASP MVC, теперь я вижу преимущества MVC, как в ответе на Cristian.

Answer 1

Есть несколько причин для этого. «Традиционный» элемент управления ASP.NET WebForm инкапсулирует аспекты Controller и View приложения MVC, что является нарушением шаблона. Кроме того, делая их методами расширения, вы получаете замечательные способности, такие как возможность замены их собственной реализацией и замены их для тестирования

Фил Хаак (руководитель программы ASP.NET MVC) немного рассказывает об этом, когда он брал интервью на подкасте Herdering Code

Эпизод 24: Фил Хаак о бета-версии ASP.NET MVC (часть 1)

http://herdingcode.com/?p=75

Эпизод 24: Фил Хаак о бета-версии ASP.NET MVC (часть 2)

http://herdingcode.com/?p=82

Answer 2

Выполнение нулевых проверок в представлении, вероятно, вызовет горе в долгосрочной перспективе. То, как я интерпретирую стиль программирования MVC, состоит в том, чтобы подготовить данные представления в контроллере, чтобы представление могло быть действительно чистым и не засеянным проверками и условиями.

С другой стороны, если есть необходимость следовать потенциально нулевым ассоциациям, совершенно нормально поместить этот код в хелпер многократного использования, например ::100100

<%= Html.BindTextBox("txtName", Model, "Person.Name") %>

Answer 3

Хорошо, для вашего второго вопроса, почему бы не сделать:

<%= Html.TextBox("txtName", ((Model != null) ? Model.Name : "")) %>

В любом случае вы должны проверить свой контроллер, чтобы убедиться, что ваша Модель не равна нулю!

Answer 4

Некоторые пуристы могут сказать, что наличие кода на ваш взгляд является нарушением парадигмы MVC. RenderPartial создает поддельный объект Page для вашего пользовательского элемента управления - убедитесь, что последний ни от чего не зависит от объекта Page.

Answer 5

Я нашел этот вопрос , где @Matt отвечает:

Имеет ли этот код А) Обрабатывать, хранить, извлекать, выполнять операции или проанализировать данные, или Б) Помогите отобразить данные?

Если ответ А, он принадлежит вашему контроллер. Если ответ B, то это принадлежит в представлении.

Если B, это в конечном итоге становится вопросом стиля. Если у вас есть довольно долго условные операции за попытку выяснить, если вы отображаете что-то пользователь, то вы можете скрыть те, условные операции в коде позади в собственности.

и я согласен. Мне чище написать в aspx:

<custom:HtmlTextBox ID="txtName" runat="server" />

и в коде что-то вроде:

if(this.Model != null) 
{
   this.txtName.Text = Model.Name;
}

чем в .aspx например:

<% if(this.Model != null) { %>
  <input type="text" name="txtName" value="<%= Model.Name %>" />
<% } else { %>
  <input type="text" name="txtName" value="" />
<% } %>

Возможность манипулировать элементами управления из кодового кода очень полезна и не нарушает шаблон MVC. Может я что-то упустил?

Спасибо!