ISV Community Day Best Practice Per Ahlberg Developer Evangelist Developer & Platform Evangelism...
-
Upload
asher-york -
Category
Documents
-
view
232 -
download
0
Transcript of ISV Community Day Best Practice Per Ahlberg Developer Evangelist Developer & Platform Evangelism...
ISV Community DayISV Community DayBest Practice
Per AhlbergDeveloper EvangelistDeveloper & Platform EvangelismMicrosoft Sweden
AgendaAgenda
General Best Practices COM Components best practice Data layer best practice ASP to ASP.NET Best Practices
General Migration StrategyGeneral Migration Strategy Identify the parts of the application that you have
to migrate Plan very carefully and try to have minimal impact
on the existing application during the migration In a multi-tier scenario, take the horizontal or
vertical approach Horizontal – migrate the whole tier
(middle/presentation) at the same time Vertical – migrate some pages, some
components, at the same time
Decide if you want to reuse existing COM components
Migration Best PracticesMigration Best Practices
Data access related If you have a data access tier, move it into .NET
COM related Always use early binding Explicitly free resources from code
Project management related Keep two code trees while migrating, and make sure to
update both of them while adding changes to the existing Web site
First try to modify the existing code as it is After you complete this, try to modify the application to
use the advantages provided by .NET
Migration Best PracticesMigration Best Practices Testing related
Update existing links to your Web site/pages because the file name extension is now .aspx
Use a link checker to check any broken links, images, paths, and so on
Test very well
Migrating Applications that Use Migrating Applications that Use COM ComponentsCOM Components COM related changes:
ASP.NET uses MTA instead of STA Pages with STA components may or may not perform
well Early binding is preferred in ASP.NET Cannot use ASPCOMPAT with WebServices
COM Interop Can use all your former COM components Use ASPCOMPAT keyword if you plan to use existing
STA components in ASP.NET Use ASPCOMPAT only when using STA objects or when
your COM objects access ASP intrinsic objects
Migration Best PracticesMigration Best Practices
Language related Strongly type all the variables If possible, convert all the On Error statements to try
catch blocks Remember that they may not be as easy as they look Use call keyword for function calls and use parenthesis
for function and subroutine calls Identify default properties and replace them
appropriately Always use Option Explicit
Remove Microsoft.VisualBasic namespace
ADO ADO ADO.NET ADO.NET
ADO evolves into ADO.NET
DataReaderDataReader
DataAdapterDataAdapter
DataSetDataSet
CommandCommand
ConnectionConnection
RecordSetRecordSet
CommandCommand
ConnectionConnection
Migrating Applications that Use Migrating Applications that Use DatabasesDatabases Data access changes
ADO (through Interop) can be used, but Microsoft does not recommend it
ADO and ADO.NET are quite different ADO.NET is not exactly backward compatible Three main objects in ADO.NET: DataSet,
DataReader, and DataAdapter Built-in designer support for ADO.NET objects
in Visual Studio .NET
Migrating Applications that Use Migrating Applications that Use DatabasesDatabases Strategies
Rewrite ADO code in ADO.NET instead of migrating Keep ADO code as a short term approach If you use ADO code in ASP pages, use Primary Interop
Assembly for ADO on both the developer box and the server
If you need read-only data, use a DataReader
High level strategies: Replace VB6 components directly by VB.NET
components, horizontally or vertically Let ASP.NET call Web Services that encapsulate VB6
business components, then migrate these as needed to .Net
Replacing VB6 components directlyReplacing VB6 components directly
Your .NET code can talk directly to VB6 COM code, but...
If your VB6 business components require passing variants, write strongly-typed “inbetween” .Net components (adapters) ASP.NET talks to the inbetween components The inbetween components talk to the
existing VB6 components and perform data conversion to strong types
VB6.MyWeakComponent:
Public Function UpdatedData(Name As String, Age As Variant, MyDataArray As Variant) As Variant
Public Function UpdatedData(Name As String, Age As Variant, MyDataArray As Variant) As Variant
VBNet.MyStrongComponent:
Public Function UpdatedData(Name As String, Age As Integer, MyDataArray As Array Of Single) As Double
Public Function UpdatedData(Name As String, Age As Integer, MyDataArray As Array Of Single) As Double
In version 1, VBNet.MyStrongComponent calls VB6.MyWeakComponent and performs type conversion as needed
Replacing VB6 components directlyReplacing VB6 components directly
.NET.NET
VB6 comp
.NET.NET
VB.NETcomp
VB6 comp
Before After
Business Business logiclogic
Adapter Adapter logiclogic
Business Business logiclogic
Replacing VB6 components directlyReplacing VB6 components directly
By building these adapter components, .NET code can be fully typed as needed and the UI can be completely replaced
As a next step, you can change the VB.NET Business components to replace the VB6 business components You have now replaced your Business logic layer
Replacing VB6 components directlyReplacing VB6 components directly
Migrating Applications that Use Migrating Applications that Use COM ComponentsCOM Components COM related changes:
.NET uses MTA instead of STA ASP.NET Pages with STA components
may or may not perform well Early binding is preferred in .NET Cannot use ASPCOMPAT with WebServices
COM Interop Can use all your former COM components Use ASPCOMPAT keyword if you plan to use existing
STA components in ASP.NET Use ASPCOMPAT only when using STA objects or when
your COM objects access ASP intrinsic objects
If your original VB6 code returned ADO Recordsets, it is best to make the VB.NET versions return ADO.NET DataSets instead: Convert ADO Recordsets to ADO.NET DataSets
as needed in the Business layer ASP.NET then works only with ADO.NET Many ASP.NET Web Controls work with
DataSets ADO.NET DataSets can be marshalled
efficiently even across physical tiers
Replacing components layer by Replacing components layer by layerlayer
Replacing components layer by Replacing components layer by layerlayer Later, migrate the Data layer and make it return
ADO.NET DataSets instead of ADO Recordsets Remove the RecordsetDataSet conversion code
from the Business components For components you can’t migrate, stick to COM
Interop
Replacing components layer by Replacing components layer by layerlayer What about transactional integrity and
security context? In VB6 under Windows NT: MTS In VB6 under Windows 2000: COM+ In .NET: COM+
Replacing components layer by Replacing components layer by layerlayer Derive your façade components from the
ServicedComponent base class to use COM+ transactions and security Interestingly, the components that a
ServicedComponent calls don’t need to be serviced – they use the caller’s context!
Use attributes to control configuration Best to put them in the AssemblyInfo.vb file
Register your façade’s assembly in the GAC
Wrapping VB6 components Wrapping VB6 components by .NET Web Servicesby .NET Web Services Alternatively, start by having your
ASP.NET pages consume .NET Web Services that wrap the VB6 components
This allows for easy separation in physical tiers (dedicated application servers) as well as logical tiers
A better option to separate in physical tiers is to use .Net Remoting
If you need transactional integrity across physical tiers, use Serviced Components
.NET.NET
VB6 comp
.NET.NET
VB6 comp
Before After
Business Business logiclogic
Adapter Adapter logiclogic
Business Business logiclogic
ASP.NET ASP.NET Web Web
ServiceService
Physical boundaryPhysical boundary
Wrapping VB6 components Wrapping VB6 components by .NET Web Servicesby .NET Web Services
.NET.NET
VB6 comp
.NET.NET
VB.NETcomp
Before After
Business Business logiclogic
Wrapper Wrapper logiclogic
Business Business logiclogic
ASP.NET ASP.NET Web Web
ServiceService
Physical boundaryPhysical boundary
Wrapping VB6 components Wrapping VB6 components by .NET Web Servicesby .NET Web Services
Web Services use open standards You can open your business logic to other
applications as well, over the Internet, if you want But be careful: Web Services can be transactional,
but only as the transactional root You can’t combine more than 1 Web Service into a
transaction
Wrapping VB6 components Wrapping VB6 components by .NET Web Servicesby .NET Web Services
ASPASP
VB6 comp
.NET.NET
VB6 comp
Replacing VB6 components Replacing VB6 components indirectly with Remotingindirectly with Remoting
Before After
Business Business logiclogic
Business Business logiclogic
Physical boundaryPhysical boundary
VB.NETcomp
Adapter Adapter logiclogic
Replacing VB6 components Replacing VB6 components indirectly with Remotingindirectly with Remoting Remoting is “.Net DCOM” Better performance than with Web Services
We measured TCP binary remoting to provide 200%-300% the speed of web services with SOAP
Calling a component through remoting does not maintain transactional integrity and security context, however
Remoting only works from .Net to .Net
COM Best PracticeCOM Best Practice
Use Primary Interop Assemblies Produced by COM API owner May be modified for correctness or managed client
friendliness Recognized by Visual Studio.NET Ensure consistent identity for Interop types
Visual Studio ships with PIAs C:\Program Files\Microsoft.NET\Primary Interop Assemblies
Office 2003 PIAs also available http://msdn.microsoft.com/library/default.asp?url
=/downloads/list/office.asp
Contain structured data: ShoppingCart, UserProfile, Catalog Are classes that inherit from DataSet Inherit all DataSet’s standard
functionalities Automatically copyable, mergable,
serializable, ... Can be autogenerated by the .NET
framework’s xsd.exe tool
Typed DataSetsTyped DataSets
ds.Tables(“Customers”).Rows(0).Columns(“Name”) _= “Steve Ballmer”
ds.Tables(“Customers”).Rows(0).Columns(“Name”) _= “Steve Ballmer”
UntypedUntyped
ds.Customers(0).Name = “Steve Ballmer”ds.Customers(0).Name = “Steve Ballmer”
TypedTyped
Typed DataSetsTyped DataSets
Add properties specific to the structured data:
IntelliSense!
They don’t solve all your data modeling needs: You still have to write code to populate them Marshalling serializable objects (such as DataSets)
rather than plain strings (such as XML strings) requires more CPU
... but the simplicity and power of using DataSets more than makes up for it
See IBuySpy reference implementation
Typed DataSetsTyped DataSets
ASP to ASP.NET Best PracticesASP to ASP.NET Best Practices
General If the application is relatively small, consider rewriting If the application is very large, then plan carefully and
migrate part by part If you only want to make a syntactic port, then consider
only ASPX pages (that is, not using the “code behind” model) and do not make unnecessary changes
You do not have to port the whole site at the same time Consider migrating the slow/critical parts Remember, you can run ASP and ASP.NET side-by-side
Try to migrate the read-only pages first Write automated tools to do some tasks
Finally Best Practices...Finally Best Practices...
Use Enterprise Templates that implement and force good coding practices
Use .Net’s standard naming conventions Use structured exception handling Use Typed DataSets rather than “generic”
DataSets whenever possible It’s not the ultimate panacea but it’s better
than generic DataSets for strong typing and IntelliSense