Drew Wutka
DWUTKA at Marlow.com
Mon Apr 6 22:47:07 CDT 2009
Before you read my >>>in-line comments, note two things: #1. As I posted to William, the original post was about 'learning' web development. So my point was that classic ASP let's you see the gears better then ASP.NET does. I have nothing against using ASP.NET. I have some issues with some people that use it, have issues with some people and screw drivers too! ;) #2. Personally, I use a tag team. I use Access or SQL Server for databases, VB 6 for business logic, HTML for the interface, and ASP is the bridge between VB and HTML. As an 'in house' developer, I don't have the pressure of keeping up to the absolute latest standard. Not too mention I'm no longer the developer (I'm now the Network Systems Administrator, though I still dabble here and there...). <snip> Yes Classic ASP is still alive and well and can certainly be used to develop web applications. And yes ASP.NET does render a lot of the server-side magic into client-side script using javascript. Do you need to know and understand all the javascript it renders to the browser? Heck no. You might need to know a smattering of javascript to get some client-side script for some tasks that cannot be handled natively by javascript. As far as ASP.NET being overkill I don't think so. >>> Overkill might be a bad term. All the client side 'magic' is handled well, but it's not perfect. In a way, this is a lot like the bound/unbound debate. With classic and unbound, there is the advantage of far more stringent control over the actual process involved. With .Net and bound, you have the advantage of prebuilt processes. It can be a coin toss in a lot of situations. 1. When you deploy your web application to the server, you simply have to upload your application's DLL and ASPX page and other supporting files (CSS, JS, etc...). With Classic ASP you need to upload all your files including your code. With ASP.NET you don't even need to upload the code behind because it's all packaged into a DLL. Works for me because I nobody can "steal" my code files since I don't have to upload them to the server. >>> Really not sure what you mean here. I usually work directly with the IIS server. So I normally don't 'upload' anything, I'm working on the live files (or working on live files in a test or development platform). I do have my core code 'compiled' as a .dll too. Plus with what I do, I use either .asp or .htm extensions, it's just a matter of tweaking the ISAPI filters to read .asp code in whatever extensions you want. 2. When you write classic ASP, the presentation layer and the code layer are interspersed in your .ASP file. Sure, you can use include files, etc...but it becomes a nightmare to maintain those files and it sure is time-consuming having to wade through both the HTML, Javascript *AND* ASP code. With ASP.NET and Visual Studio you can use the object oriented approach and have all the intellisense at your fingertips so that you can easily find a function or a sub in your code file which is totally separate from your HTML code. >>>Wouldn't say this is an advantage, just a different style. I never have problems finding anything in my asp code, of course most of what I do now is 'condition coding', ie, HTML interspersed with the .asp. 3. ASP.NET has field validator controls that render the appropriate client-side script for validating required fields, range validation, custom validation, etc...You can drag and drop the validation controls, type an error message and specify the ASP.NET control to validate and never have to worry about writing the same javascript code over and over again for those situations. This facility alone makes ASP.NET better than classic ASP development. >>> This is an advantage and disadvantage. I build my data validation into the VB code. What is returned is a simple message to the end user as to what needs to be changed. It's pretty simple to do. So the advantage of the .Net method is that you have prebuilt processes that can alert immediately, and even correct the user. The disadvantage is that it can be bypassed. And an advantage of my method is that automation is easier. I've built several apps for 'side work' clients, where I 'upload' a users data into a site built by someone else. When that site is loaded with Javascript data validation, it 'breaks' the automation. My method would allow an automated process to enter the data, and then retrieve a valid/invalid response. 4. Uploading files and sending mail via SMTP are handled by ASP.NET binaries which means that you don't need third party libraries to upload files or send mail via your web apps which you have to do with classic ASP. >>>Matter of style again. I have a single .asp file to allow users to upload files (I just copy the file, not very hard), and sending mail is a .dll I have already built (actually, one is ASPEmail, the other is a custom one I built which uses a special email handler). 5. Postbacks are handled differently in ASP.NET compared to classic ASP. You can check for postbacks and check if the page is valid (if there are field validators that were triggered) very easily compared to classic ASP where you have to write those functions yourself. >>> Actually, I believe they are handled the same way, ASP.NET is just automating it. Definitely an advantage for .NET 6. Viewstate is also handled better in ASP.NET. Ever wanted to preserve the value of some control in classic ASP? You'll need to write Request.Form() constructs for each form control you want to pass on to the next page. ASP.NET does that for you. >>>Another style issue. I handle everything in my .dll. Most of the time I am recording the data then and there, though to pass information to another page there is always a session variable to hold the info. No big deal. 7. You can write your data handler functions and compile them into a library (DLL) and reference them in any web app so that you have a standard way of interfacing with back-end databases. Classic ASP doesn't compile your code. Sure you can copy and paste all those custom functions into every classic ASP project you work on. But is that really being efficient? >>> Again, using a VB .dll. It can be ported to any web app or for that matter, any system that can use an ActiveX .dll. So yeah...ASP.NET is overkill if you want to build a lot of the built-in stuff yourself. :) The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI Business Sensitive material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited.