Ответ. Записать устаревший?

Есть много других способов. Я избегаю использования Response.Write, потому что это зависит от точного порядка, в котором что-то записывается на выходе. Я бы предпочел использовать, например, элемент управления Literal и присвоить значение его свойству Text.

Я обычно также стараюсь избегать встроенных операторов <% = (return a value here)%>, так как мне нравится сохранять страницу aspx чтобы содержать только структуру страницы и хранить операторы кода на стороне сервера в файле кода программной части.

В тегах aspx - встроенных серверных скриптов:

<%= SomeProperty.Name %>

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

Зависит от вашего приложения. Помните, что <% = "some string"%> в вашем файле .aspx по-прежнему является ярлыком для Response.Write ()

Если вы рендерили весь свой HTML-код с помощью функции Response.Write (), то да, возможно, он право. Но если вы использовали его для встроенного кода, то это действительно нормально.

Я бы не стал отказываться от него, если этот метод не отмечен как устаревший. Это, конечно, не «старомодно». Но могут быть случаи, когда есть лучшие альтернативы, поскольку они более удобны в обслуживании.

Например, вы могли бы подумать о написании группы <% =%> операторов в вашем HTML, но это было введено в то же время, что и HttpResponse.Write, поэтому, если один из них «старомоден», они оба.

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

Если ваш интервьюер не хотел вдаваться в подробности, это тоже кое-что говорит об интервьюере.

Я не думаю, что «старомодный» - это правильный термин, который интервьюер действительно хотел сказать. В зависимости от контекста могут быть более эффективные методы. Если вы используете встроенные теги скрипта, такие как пример Джейсона, тогда соглашение <% = может лучше подойти для этой задачи. Однако, если вы выполняете какую-либо логику просмотра, <% if (* conditional *) {...}%> , тогда ваши альтернативы могут быть ограничены.

Это полностью зависит от того, для чего вы использовали Response.Write.

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

Вероятно, в определенных обстоятельствах вам понадобится Response.Write.

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

У нас есть устаревший код, в котором весь HTML-вывод был создан в VB DLL как таковой, в то время , был самым быстрым способом создания HTML с распределенным управлением транзакциями.

Однако ASP.NET отчасти сводил на нет необходимость в этом, потому что он скомпилировал файлы aspx и код за вас в библиотеки DLL.

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

Просто снимок в темноте, но вы предлагали использовать Response.write для отладки? Что-то вроде:

Response.Write("Inside first loop.");

Если так, я бы сказал, что он устарел, учитывая новые инструменты отладки в Visual Studio / .NET.

Страница ASP.Net - это высокоструктурированная часть программного обеспечения, состоящая из иерархии элементов управления, которые несут ответственность за предоставление собственной продукции. В этом режиме Response.Write кажется устаревшим, потому что он восходит к исходным страницам ASP, где все было отображено встроенным.

Современные страницы просто обновляют свойства элементов управления, которые выводят собственный вывод. Response.Write нарушает иерархию, прерывая поток управляющих выходных данных.