当前位置：编程学习 > C#/ASP.NET >>
答案：Using Parentheses with Method Calls
In ASP, you could freely call methods on objects without using parentheses, as shown below:Sub WriteData() Response.Write "This is data"End SubWriteData
In ASP .NET, you must use parentheses with all of your calls, even for methods that do not take any parameters. Writing your code, as in the example below, allows it to function correctly in both ASP and ASP .NET.Sub WriteData() Response.Write("This is data")End SubCall WriteData()ByVal Is Now the Default
In Visual Basic, all parameter arguments were, by default, passed by reference or ByRef. In Visual Basic .NET, this has changed so that all arguments are now passed by value or ByVal by default. If you still wish to have "ByRef" behavior, you must explicitly use the ByRef keyword in front of your parameters as follows:Sub MyByRefSub (ByRef Value) Value = 53;End Sub
This is an area where you really need to be careful. When you are moving your code over to ASP .NET, I suggest double and triple checking each parameter used in your method calls to ensure that this change is what you really want. I suspect you will need to change some of them.No More Default Properties
The concept of default properties no longer exists in Visual Basic .NET. What this means is that if you have ASP code that relies on a default property that was provided by one of your objects, you will need to change this to explicitly reference the desired property, as shown in the following code:'ASP Syntax (Implicit retrieval of Column Value property)Set Conn = Server.CreateObject("ADODB.Connection")Conn.Open("TestDB")Set RS = Conn.Execute("Select * from Products")Response.Write RS("Name")'ASP.NET Syntax (Explicit retrieval of Column Value property)Conn = Server.CreateObject("ADODB.Connection")Conn.Open("TestDB")RS = Conn.Execute("Select * from Products")Response.Write (RS("Name").Value)Changes in Data Types
In Visual Basic .NET, Integer values are now 32 bits and Long types have become 64 bits.
Problems may arise when invoking methods on COM objects from ASP .NET or calling Microsoft® Win32® API calls inside your custom Visual Basic components. Pay special attention to the actual data types required to ensure you are passing in or casting your values correctly.Structured Exception Handling
Although the familiar On Error Resume Next and On Error Goto error handling techniques are still allowed in Visual Basic .NET, they are not the best way to do things anymore. Visual Basic now has full-blown structured exception handing using the Try, Catch, and Finally keywords. If possible, you should move to this new model for error handling as it allows for a more powerful and consistent mechanism in dealing with your application errors.COM-Related Changes
With the introduction of the .NET Framework and ASP .NET, COM really has not been changed at all. This does not mean, however, that you do not need to worry about COM objects and how they behave when you are using them from ASP .NET. There are a couple of fundamental things you need to be aware of.Threading Model Changes
The ASP .NET threading model is the Multiple Threaded Apartment (MTA). What this means is that components that you are using that were created for the Single Threaded Apartment (STA) will no longer perform or function reliably without taking some extra precautions in ASP .NET. This includes, but is not limited to, all COM components that have been created using Visual Basic 6.0 and earlier versions.ASPCOMPAT Attribute
You will be glad to hear that you can still use these STA components without having to change any code. What you need to do is include the compatibility attribute aspcompat=true in a <%@Page> tag on the ASP .NET page. For example, <%@Page aspcompat=true Language=VB%>. Using this attribute will force your page to execute in STA mode, thus ensuring your component will continue to function correctly. If you attempt to use an STA component without specifying this tag, the run time will throw an exception.
Setting this attribute to true will also allow your page to call COM+ 1.0 components that require access to the unmanaged ASP built-in objects. These are accessible via the ObjectContext object.
If you set this tag to true, your performance will degrade slightly. I suggest doing this only if you absolutely need to.Early Binding Versus Late Binding
In ASP, all calls to COM objects occur through the IDispatch interface. This is known as "late binding" because calls to the actual objects are handled indirectly via IDispatch at run time. In ASP .NET, you can continue to invoke your components in this fashion if you like.Dim Obj As ObjectObj = Server.CreateObject("ProgID")Obj.MyMethodCall
This works but it is not the preferred manner to access your components. With ASP .NET, you can now take advantage of early binding and create your objects directly as follows:Dim Obj As New MyObjectMyObject.MyMethodCall()
Early binding allows you to interact with your components in a type-safe manner. In order to take advantage of early binding with your COM components, you need to add a reference in your project in much the same way that you add a COM reference to a Visual Basic 6.0 project. Assuming that you are using Visual Studio .NET, a managed proxy object is created behind the scenes, on top of your COM component, giving you the impression you are dealing directly with your COM component as a .NET component.
At this point you may wonder about performance. There is definitely some overhead involved when using COM interoperability as you now have an extra layer introduced because of the proxy object. In most cases, however, this will not be a factor because the amount of actual CPU instructions for the interoperation to occur is still substantially less than that required by your indirect IDispatch calls. You will be gaining more than you will lose. The ideal situation, of course, is to use newly created, managed objects, but we know that this will not always be possible immediately because of our investments in COM components over the years.OnStartPage and OnEndPage Methods
One area that needs some additional consideration involves the use of the legacy OnStartPage and OnEndPage methods. If you rely on these methods to access ASP intrinsic objects, you will need to use the ASPCOMPAT directive and use Server.CreateObject to create your component in an early-bound fashion, as shown below:Dim Obj As MyObjObj = Server.CreateObject(MyObj)Obj.MyMethodCall()
Notice that instead of using the "ProgID," we have used the actual type in an early-bound manner. In order for this to work, you will need to add a reference to your COM component in your Visual Studio project so that the early-bound wrapper class is created for you. This should be the only case where you must continue to use Server.CreateObject.COM Summary
Table 2 is a summary of what you need to do to continue to use your COM components as efficiently as possible.
Table 2. ASP .NET Settings for Legacy COM Objects
| Custom STA (Visual Basic Components or other components marked as "Apartment") | Use ASPCOMPAT, use early binding 上一个：asp.net key considerations(三) 更多图片编程知识:
CopyRight © 2012 站长网 编程知识问答 www.zzzyk.com All Rights Reserved
部份技术文章来自网络， |
