我最近参加了一次技术面试,其中我使用了Response.Write()。面试官告诉我这种方法已经过时了,现在有更好的方法。然而面试官没有进一步解释,所以我很想知道他指的是什么。有人有任何想法吗?
如果页面上所有的内容都是由Response.Write输出的,那么Response.Write非常好用。当我需要使用ASPX动态生成非HTML文件时,我就会使用它。
如果你正在使用非空的ASPX页面,使用Response.Write将毫无意义。
<%= SomeProperty.Name %>
还有许多其他方法。我避免使用Response.Write,因为它取决于输出的确切顺序。我更喜欢使用Literal控件,并将值分配给其Text属性。
通常,我也会尽量避免使用<%=(在此返回值)%>内联语句,因为我喜欢仅在aspx页面中包含页面结构,并将服务器端代码语句保留在代码后台文件中。
Response.Write
似乎已经过时了,因为它回溯到最初的ASP页面,其中所有内容都是内联呈现的。Response.Write
通过中断控件输出的流程来破坏层次结构。取决于你的应用程序。记住,在你的 .aspx 文件中,<%= "some string" %> 仍然是 Response.Write() 的快捷方式。
如果你正在使用 Response.Write() 函数来渲染所有的 HTML,则他可能是正确的。但如果你正在使用它来进行内联代码,那么它其实还是可以的。
<%= %>
语句,但是这与HttpResponse.Write同时引入,因此如果其中一个是“老式方法”,则两者都是。在其他情况下,您可能还想考虑使用模板引擎。这完全取决于具体情况。如果您的面试官不想详细解释,那也说明了面试官的问题。只是尝试一下,但你有考虑使用 Response.write 进行调试吗?就像这样:
Response.Write("Inside first loop.");
<%=
约定可能更适合该任务。但是,如果您正在执行任何类型的视图逻辑,<% if (*conditional*) { ... } %>
那么您的选择可能会受到限制。这完全取决于您使用 Response.Write 的目的。
如果它是为了将字符串输出到页面上进行显示,那么也许您应该在页面上放置一个 Literal,然后设置该字面量的文本,而不是使用 Response.Write。
在编程中,可能存在某些情况下你需要使用 Response.Write。
比如说,如果你想通过字节数组将数据库中存储的图像流式传输到页面上,我认为你只能使用 Response.Write 来实现。