Sunday, October 28, 2007

Web applications aren't the solution to every problem

I've been working on an ASP.NET website for a while now. For the admin side of things, I've added a few pages for updating the database and such like. There have always been problems with updating the data, which is read in from some text files and then dumped in the database. First there were problems with the size of the data in the files, which was solved initially via the maxRequestLength attribute in web.config. Then the file upload to the web server was still taking a long time so I started to require the data to be uploaded via Remote Desktop or FTP. Then I had problems with the SQL update timing out. This was solved by increasing the value of the executionTimeout attribute in web.config. But after a while even this didn't work and the update failed when the request timed out. I could probably increase the timeout some more or I could use some other technique to get it working, but I eventually came to the conclusion that this just isn't what I should be doing. ASP.NET sets these values quite low for a reason, it's just trying to protect itself from poorly written applications. A request to a web server should take as short a time as possible before getting the hell out of there. That's what the web sever is designed to handle.

So I ripped out the code and dumped it in a WinForms application. WinForms has no problems with threads that hang around for a long time so that solved my initial problem. And, even better, I can give feedback to the user very easily, without fiddling round with AJAX. It's also more secure. Remote desktop connections to this server are only accepted from certain IP addresses, whereas anyone might find the admin pages (even though they are password protected).

So to the moral of the story, remember that not every problem is a nail and there are other tools in your toolbox other than the hammer.

No comments: