Migrating from ASP to ASP.NET - Recomendation for Best Practices (Page 11 of 11 ) Now that you have been exposed to most of the issues you are likely to encounter, you may be wondering what things you can do today to be better prepared for them when you finally move to ASP.NET. Quite a few things can be done that will make the process smoother. Many of these suggestions will be beneficial to your ASP code even if you do not move to ASP.NET until sometime in the future. - Use parentheses and Call statements wherever possible, as detailed earlier in this article. In ASP.NET you will be forced to use parentheses. Using the Call statement today will help you add a bit of discipline that will better prepare you for the future.
- Avoid nested include files. That means, you should try to eliminate any areas where you have include files that include other include files. What tends to happen over time is that your code ends up relying on a global variable that is defined in an include file somewhere else, and you are getting access to it only because you have included another file that includes the one you really need. When you migrate to ASP.NET, you will most likely be moving your global variables and routines into class libraries, in which case, it is much easier to do if you have a clear picture of where you are getting access to everything. You may end up having to move things around and change some routines' names that were duplicated in multiple files.
- One strategy used in the migration process is to migrate all of the utility functions and code contained in your server-side include files into Visual Basic or C# class libraries. This allows you to finally put all of the code where it belongs—in objects, as opposed to multiple-interpreted ASP files.
- If you have a bunch of global variables or constants mixed in server-side include files, consider placing all of them in a single file, as well. Once you move to ASP.NET, you can then easily create a class that will house your global or constant data. This will make for a much cleaner and more maintainable system.
- If at all possible, you should separate your code from HTML content. Clean up functions that mix code and script throughout a function body. Doing so puts you in a much better position to leverage code-behind as this is the ideal model under ASP.NET anyway.
- This is not supported in ASP.NET. You should be declaring your functions inside <script> blocks.
- Make sure you explicitly call any close() or cleanup methods that exist on the objects and resources you may be using. We all know how forgiving Visual Basic and VBScript are when it comes to cleanup. Normally, they are pretty good at cleaning things up immediately but, as we move to .NET and the garbage-collected world, one cannot be sure exactly when objects will be cleaned up. If you can cleanup and release your resource explicitly, you should.
- If possible, you should avoid intermixing server-side VBScript and JScript in the same page. In general, this is a poor programming practice anyway. This is also a migration issue for ASP.NET in that it requires only one inline <% %> language per page because of the new compilation model. You can continue to emit client-side script in the same manner as you are used to.
Conclusion This document covered some of the more powerful features that can simplify Web development while providing a more scalable, stable, and productive environment. Although there is certainly a learning curve associated with migrating from ASP to ASP.NET, the effort is well worth it due to the numerous productivity features offered by the .NET framework and ASP.NET. | DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
|