Response.Write outdated?

Question

I recently had a techical test for a job interview where I did a Response.Write(). I was told that this was "old fashioned" and that there are better ways of doing this now. The interviewer wouldn't elaborate, so I'm keen to know what he was referring to. Anyone have any ideas?

Answer 1

Depends on your application. Remember that <%= "some string" %> in your .aspx file is still a shortcut for Response.Write()

If you were rendering all your HTML using the Response.Write() function, then yeah, maybe he's right. But if you were using it for inline code, then it's actually pretty ok.

Answer 2

There are many other ways. I avoid using Response.Write because it depends on the exact order in which things are written to the output. I would rather use for instance a Literal control and assign a value to its Text property.

I usually also try to avoid the <%= (return a value here) %> inline statements, since I like to keep the aspx page to only contain page structure, and keep server-side code statements in the code-behind file.

Answer 3

In the aspx - inline server script tags:

<%= SomeProperty.Name %>

In the code - that depends on the circumstances but there's usually a better alternative such as a HtmlTextWriter, a ScriptManager (for registering your scripts), a literal control, a placeholder or something else.

Answer 4

Unless that method is marked as obsolete, I wouldn't dismiss it. It's certainly not "old fashioned". But there may be cases where there are better alternatives, for they are more maintainable.

For example, you could consider writing a bunch of <%= %> statements in your HTML, but that was introduced at the same time as HttpResponse.Write, so if one of them is "old fashioned", they both are.

You might also want to consider using a templating engine in other cases. It all depends.

If your interviewer didn't want to elaborate, that also says something about the interviewer.

Answer 5

I don't think "old fashioned" is the correct term the interviewer was really wanting to say. There may be better methods to use depending on context. If you are using inline script tags, such as Jason's example, then the <%= convention may be better suited to the task. However, if you doing any kind of View logic, <% if (*conditional*) { ... } %> then your alternatives may be limited.

Answer 6

It depends entirely on what you used Response.Write for.

If it was to output a string for display to the page, then maybe you should've put a Literal on the page and then set the Text of that literal rather than doing a Response.Write.

Answer 7

Response.Write is great, if everything on the page is sent by it. I use it when I have to use ASPX to serve non-HTML files that I generate on the fly.

Response.Write doesn't make any sense at all if you are using non-empty ASPX pages.

Answer 8

There are probably certain circumstances where you need Response.Write.

Supposing you were storing images in a database and wanted to stream them via a byte array onto your page. I don't think you'd be able to do it without Response.Write.

Answer 9

We have some legacy code where all the HTML output was created in VB DLL's as it, at the time, was the fastest way of creating HTML with distributed transaction control.

However ASP.NET kind of negated the need for that because it compiled the aspx files and code behind to DLL's for you.

Response.Write is still OK for specific tasks, however the vast majority of coding no longer needs to do that.

Answer 10

Just a shot in the dark, but did you propose using Response.write for debugging? Something like :

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

If so, I'd say it is outdated given the new debugging tools in Visual Studio/.NET.

Answer 11

An ASP.Net page is a highly structured piece of software consisting of a hierarchy of controls that are responsible for providing their own output. Within this regime, Response.Write seems outdated because it harkens back to the original ASP pages where everything was rendered inline.

Modern pages just update properties of controls that render their own output. Response.Write breaks the hierarchy by interrupting the flow of the control output.