ASP.NET移植须知(4)

     使用Option Explicit
  
  这是个很好的建议，但并不是每个人都使用它. 当在ASP中使用Option Explicit来强制变量声明时, 您会至少清楚地了解所有内容在哪里定义，及变量如何定义。一旦转到ASP.NET, 我建议您使用Option Strict. Option Explicit 在Visual Basic.NET中是默认的。 但是，如果使用更具强制性的Option Strict, 您就能确保所有的变量都被声明为正确的数据类型. 虽然这势必增添额外工作量，但是长远看来，您将会发现这是很值得的。
  
  
  避免使用默认属性
  
  正如我们所讨论的，默认的属性将不再被允许。访问属性原本就不是很困难的事。这会使您的代码更具可读性，同时，将来移植时也会更节省时间.
  
  
  使用括号 和Call关键字
  
  就如本文前面所描述的一样，应尽可能的使用括号和Call 语句。 在 ASP .NET 中您将会被迫使用括号。现在就使用Call语句助您早日养成优良编程习惯，以更好的适应将来的需求。
  
  
  避免嵌套式包含文件
  
  这点说来容易，做起来难。但是，您应该尽可能地避免嵌套您的包含文件。说得更清楚一点就是， 您应当最大幅度避免重复嵌套文件。久而久之，往往发生的情况是，您的代码不得不依赖于一个全局变量，而该变量又是在其他地方的包含文件中被定义。您能够访问它是因为您的某个包含文件包含了这个您正真需要的包含文件。
  
  当您转向ASP .NET,您将很有可能将您的全局变量和程序移入类库中。这时如果您了解在哪里访问所有内容，就会方便很多。最后您也许不得不重新放置些文件，并改变一些重名例程的名字。
  
  
  将功能函数组织成单个文件
  
  在移植过程中的一个策略就是把功能函数和代码转移到Visual Basic 或C#类库中。相对于多重解释型的ASP文件，您最终可以把所有的代码放进它所属的对象。提前组织您的代码会节省您未来的时间。在最理想的状态下，您应该可以将子程序编组为逻辑文件。这样您就能够非常容易地创建一组VB或者C#类。这些功能在COM 对象中恐怕早就该有了。
  
  如果在服务器端的包含文件中您有很多混合的全局变量或常数，不妨将他们也放到一个文件中。一旦您转向ASP.NET,您将能很容易的创建一个能容纳您所有全局变量或常数的类。这样您会有一个更有条理，更容易维护的系统。
  
  
  尽可能地从内容中移掉代码
  
  您应尽可能的将您的代码从HTML的内容中分离开来，这是另一个易说难做的工作。把混有代码和脚本的函数体清除出函数。这样做的话，您就会跟好的实现代码隐藏，因为这是一个ASP.NET下的理想模式。
  
  
  请勿在<%%>块中声明函数
  
  在ASP.NET中，这种写法已经不支持了。您应该把您的函数声明在<script>块内。请参考前面结构变化部分中的例子。
  
  
  避免输出(Render) 函数
  
  与先前讨论的一样，您应该避免使用输出函数。如果现在您能改变或准备您的代码，当组建这些类型的函数时，您应该使用”Response.Write”语句块。
  
  
  明确地释放资源 （调用Close方法）
  
  请尽量明确地调用任何Close()或您所用对象与资源的释放方法。就释放而言，我们都知道Visual Basic 与VBScript会自动释放资源。它们一般都能立刻释放资源，但是，当我们转向.NET，我们没法确切地知道资源何时被释放。所以您应该尽可能显示地释放资源。
  
  
  避免混合语言
  
  如果有可能的话，您应该避免在同一页上混合服务器端的VBScript 与Jscript。总的来说，混合不同语言的做法本来就是很糟糕的编程习惯。由于新的编译模式的变化，每页要求在<%%>块内只能有一种语言。这也是一个向ASP.NET 移植时要注意的问题。您可以继续使用你习惯的方式编写客户端脚本。
  
  
  总结
  综上所述，在您把您的应用程序迁至ASP.NET时，您需要注意相当多的方面。我在本文中提出的大多变化应该都是很容易实施的。
  如果您的网站很大，当您完成这一过程时，您发现并修复的死代码，低效程序，bug的数量，可能会多得足以让您惊叹。同时，您将能充分享受ASP.NET 乃至整个.NET平台所带来的众多强大功能。
  
  

原文转自：http://www.ltesting.net