ASP.NET移植须知(3)

     线程模式变化
  
  ASP.NET线程模式是Multiple Threaded Apartment (MTA).　这就是说，您所用的为Single Threaded Apartment (STA)而生成的组件，在ASP.NET中，如不采取特别预防措施，不再会可靠工作。这包括，但不局限于，用Visual Basic 6.0及先前版本生成的所有COM组件。
  
  
  ASPCOMPAT 属性
  
  现有的STA组件不需要任何修改就能使用。 您所要做的仅仅是在ASP.NET页面的<%@Page>标签中加入指示兼容的属性aspcompat=true。比如，<%@Page aspcompat=true Language=VB%>。使用这个属性会强制该页面在STA模式下执行，从而确保您的组件正常工作。如果您的页面不指定本属性而直接引用STA组件，在运行时将发生异常。
  
  设置aspcompat=true也将使您的页面能够调用那些需要使用ASP内建对象的COM+1.0组件。这可以通过ObjectConect对象来实现。
  
  设置本属性会导致一定的性能下降。我建议您仅在必要的情况下使用它。
  
  
  预先绑定与滞后绑定
  
  在ASP中，所有对COM组件的调用都是通过IDispatch接口进行的。由于所有调用都需要在运行时由IDispatch间接处理，我们称之为滞后绑定。在ASP.NET中，如果您愿意，您仍然可以使用这种方式来完成对象调用。
  Dim Obj As Object
  Obj = Server.CreateObject("ProgID")
  Obj.MyMethodCall
  
  以上代码能够工作，但这并不是我们所推荐的用法。在ASP.NET中，您可以利用预先绑定直接创建您需要的对象：
  Dim Obj As New MyObject
  MyObject.MyMethodCall()
  
  预先绑定能使您的页面在与组件的交互过程中避免出现类型错误。为了使用预先绑定，您需要在项目中加入一个引用，正如您在VB6.0项目中加入一个COM组件引用一样。假设您使用的开发工具是Visual Studio.NET，VS.net将会在后台创建一个位于COM组件之上的代理对象，让您感到就像在使用.NET组件一样方便。
  
  至此您可能会提出性能问题。为了保证与COM的互操作性，我们引入了代理对象，这的确会带来一定的性能负担。然而，在大多数情况下，您并不需要担心由此而引发的性能下降。毕竟，与冗长的IDispatch调用相比，代理对象所执行的CPU指令几乎可以忽略不计。您所赢得的远远超过您所失去的性能。当然，理想的状况是完全使用新创建的，被管理的(Managed)对象。然而，理想状况近期还不可能达到——我们必须保护在过去几年里对COM技术的投资。
  
  
  OnStartPage和OnEndPage方法
  
  在使用传统的OnStartPage和OnEndPage方法问题上，您可能需要多花一些时间。如果您依赖于这两个方法来访问ASP固有对象，那么您需要使用ASPCOMPAT指令，然后用Server.CreateObject以预先绑定的方式来创建对象。见下例：
  Dim Obj As MyObj
  Obj = Server.CreateObject(MyObj)
  Obj.MyMethodCall()
  
  请注意我们没有用“ProgID”，而是用了预先绑定的实际对象类型。为了保证以上代码正常工作，您需要在Visual Studio项目中加入对该COM组件的引用，以便VS创建一个预先绑定的包装类。这里是您必须继续使用Server.CreateObject的唯一理由。
  
  
  COM小结
  
  表2列出了您为了继续有效使用现有的COM组件所必须做的事情。
  
  表2. 传统COM对象的ASP.NET设置
  
  COM 组件类型/方法
  　ASP .NET 设置/例程
  
  Custom STA (Visual Basic 组件 或其它被标志为"Apartment"的组件)
  　使用 ASPCOMPAT属性, 和预先绑定
  Custom MTA (或其它被标志为"Both" or "Free" 的ATL 或自定义的 COM组件)
  　使用预先绑定,不当但不要用 ASPCOMPAT属性
  内置对象 (通过ObjectContext 对象来访问)
  　使用 ASPCOMPAT属性, 和预先绑定
  OnStartPage, OnEndPage
  　使用 ASPCOMPAT属性, 和Server.CreateObject(Type)
  
  无论您的组件是否使用COM+来部署，以上设置都适用。
  
  在ASP中，Web应用程序的配置信息都存放在系统注册表或IIS的配置数据库(Metabase)中。在很多情况下，由于服务器缺乏适当的管理工具，察看或修改这些设置成为非常困难的一项工作。ASP.NET引入了全新的，基于简单、可读的XML文件的配置模式。ASP.NET应用程序在自己的目录下有一个Web.Config文件。您可以通过修改Web.Config文件来控制应用程序的自定义配置，行为，和改变它的安全属性。
  
  由于习惯的作用，您可能像我一样还是忍不住要打开Internet Service Manager来查看或修改ASP.NET应用程序的配置。然而，您必须理解，我们现在有两套独立的配置模式。除了一些安全设置，绝大多数由IIS管理工具所生成的设置都会被ASP.NET应用程序忽略。您需要把这些设置放在Web.Config文件里。
  
  关于.NET应用程序的设置有专门的文章讨论，我这里不再赘述。表3列出了一些比较有趣的配置。请记住还有非常多的配置项目没有列在这张表中。
  
  表3. Web.Config 文件设置范例
  
  项目
  描述
  
  <appSettings>
  　定制应用程序配置
  <authentication>
  　设定ASP.NET应用程序对身份验证的支持
  <pages>
  　设定页面相关的配置
  <processModel>
  　设置ASP.NET在IIS系统中的进程模式
  <sessionState>
  　指定一些会话状态选项　
  
  .NET基本类库中有一些类可以用来在程序中简化应用程序配置访问方式。
  
  如果您的应用程序使用了Session或Application固有对象来存储状态信息，那么它仍然能够在ASP.NET中正确运行。在ASP.NET中，您有了更多的选择来存储状态相关的数据。
  
  
  可用的状态管理方法
  
  ASP.NET提供了更多的状态存储摸式。这使您的应用程序能够跨越多个Web服务器支持Web farm范围内的状态管理。
  
  您可以用Web.Config文件中的<sessionState>部分来配置状态管理选项。见下例:
  <sessionState
  mode="Inproc"
  stateConnectionString="tcpip=127.0.0.1:42424"
  sqlConnectionString="data source=127.0.0.1;user id=sa;password=" cookieless="false"
  timeout="20"
  />
  
  mode属性指定了您想要存储状态信息的位置。您可以选择的状态包括Inproc, StateServer, SqlServer, 及Off。
  
  表 4. 会话状态存储信息
  
  选项
  描述
  
  Inproc
  　会话状态存储于服务器本地。(ASP 风格)。
  StateServer
  　会话状态存储于远程或本地的状态服务进程。
  SqlServer
  　会话状态存储于SQL 服务器数据库。
  Off
  　会话状态被关闭。
  
  当你选用StateServer状态，StateConnectionString 会起作用；而当您使用SqlServer状态， sqlConnectionString会起作用。对于每个应用程序，您仅可以使用一个存储选项。
  
  
  存储COM组件
  
  需要记住的一点是如果您依赖在您的Session 或Application对象中的传统COM组件的存储引用，您就不可以在应用程序中使用新的状态存储机制(StateServer 或SqlServer)。您只能使用Inproc。这是因为在.NET中, 那些对象需要能够自我序列化, 但显然COM 组件做不到. 相反, 您新创建的管理(Managed)组件可以相对容易实现这一点，当然也就可以使用新状态存储模式。
  
  性能
  
  提到性能，当然没有免费可言。可以保证的是，在大多数的情况下，Inproc会继续保持其性能之最。紧随其后的是StateServer和SqlServr。您应当用您的应用程序进行专门测试，以作出最符合您性能要求的选择。
  
  
  在ASP和ASP.NET中共享状态　
  
  另一个应当注意的问题是虽然您的工具能够容纳ASP和ASP.NET网页，但是您不能共享固有会话或应用对象的状态变量。您可以将信息在两个系统中进行复制，也可以在您的应用程序完全移植前，提供一个自定义的解决方法。底线是：如果您对Session和Application对象运用很少，您不会受到很大影响。但就另一方面而言，如果您对这些对象运用很多，您则需要谨慎的运用。您或许可以考虑采自定义一个短期解决方法以共享状态。
  
  安全性是又一个值得关注的地方。这里提供的是对ASP.NET安全系统的简要概括。要获得更详尽的信息，请参阅ASP.NET安全系统的有关文件。
  
  ASP .NET的安全性主要由web.config文件中的安全设置部分来控制。ASP .NET与IIS协调一致，紧密配合，为您的应用程序提供一个完整的安全模式。一些极少数的IIS 安全性设置会以在ASP中同样的方式被ASP.NET继承和运用。当然，它还有许多附加的增强组件。
  
  
  身份验证
  
  对于身份验证，ASP.NET支持列表5中的不同选项。
  
  列表5. ASP .NET 身份验证的选项
  
  类型
  描述
  
  Windows
  　ASP .NET用Windows 身份验证.
  Forms
  　基于Cookie,自定义登录表.
  Passport
  　微软对外提供Passport 服务.
  None
  　没有进行身份验证
  
  除了新的Passport 身份验证选项以外，这些选项在ASP中是相同的。以Windows为基础的身份验证在以下例子中的配置下能得到运用。
  <configuration>
  <system.web>
  <authentication mode="Windows"/>
  </system.web>
  </configuration>
  
  
  授权
  
  当您的用户通过身份验证之后，您可以对希望他们访问的资源进行授权。以下例子说明访问权限被授予“jkieley”和“jstegman”，任何其他人都将被拒绝访问。
  <authorization>
  <allow users="NORTHAMERICA\jkieley, REDMOND\jstegman"/>
  <deny users="*"/>
  </authorization>
  
  
  扮演
  
  扮演是指一个对象以另一个实体身份标识来执行代码的过程. 在 ASP中, 扮演将允许您的代码由授权用户运行.同样的，您的用户能够在一个特殊的标识下匿名运行。在默认情况下，ASP.NET对模拟并不是有求必应。这与ASP是不同的。如果您依赖这个功能，您需要在您的web.config文件中，如下所示，激活该功能。
  <identity>
  <impersonation enable = "true"/>
  </identity>
  
  在移植时另一个要注意的关键是数据访问。通过ADO.NET的介绍，您现在有了一个高效的新方法来获取数据。因为数据访问就它本身而言是个很大的话题，所以它已超出了本文的范围。对大多数情况而言，您能像以前一样继续使用ADO，但是我仍推荐您看一下ADO.NET。这是在您ASP.NET应用程序中改进数据访问方法的一种有效途径。
  
  
  使用ASP .NET的准备工作
  
  现在您已知道了大多数您可能碰到的问题，您也许想知道在最终转向ASP.NET之前的今天您该做些什么以做好准备。为了让过程更顺利，有很多工作可以做。即使您将来不转向ASP.NET，这里的许多建议对您的ASP代码也是有帮助的。
  
  
  
  

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