Overgang fra COM+ til .NET

[alfred97]

Her må noen hjelpe en stakkars .NET-n00b.

 

Har et gammelt system som er kodet i VB6, men som vurderes oppgradert til .NET. Systemet består av en standard trelagsstruktur med en klientapplikasjon (desktop, ikke web) som knytter seg opp mot en server, som i sin tur har en database i bunnen. Serveren består av et antall komponenter av typen COM+, som hver tilbyr sitt sett av funksjoner ut mot klienten.

 

Jeg forstår det sånn at jeg kan velge å fortsette å bruke COM+ selv om jeg skriver koden om til .NET, men at .NET tilbyr andre (og bedre?) mekanismer som "erstatter" COM+ og nærmest gjør COM+ avleggs. Hva er det som er vanlig praksis?

[GeirGrusom]

Det er tusen grunner til å velge .NET fremfor COM+ og ihvertfall VB6.

 

Men det kommer an på kravene kundene dine har. Det vil bli vanskeligere og vanskeligere å distribuere programmer skrevet i VB6, og .NET vil føre til at du må skrive mindre kode for å gjøre mer.

 

.NET gir støtte for 64-bit, utvidet instruksjonssett, flere datatyper, fullstendig objektorientering, lambdauttrykk og generics. Ved siden av dette, får du også et vesentlig større standardbibliotek som gjør hverdagen enklere.

 

.NET fungerer dog mer eller mindre sømløst med COM+ så det er bare å sjekke litt rundt. Men det er anbefalt å flytte så mye som mulig til .NET.

[alfred97]

Ja, altså, jeg er ikke ute etter argumenter for eller imot å gå over til .NET. Mulig jeg uttrykte meg uklart - jeg vil altså vite hvordan, ikke hvorfor.

 

Jeg er ute etter en kjapp beskrivelse av hvordan et slikt system vanligvis bygges opp, gitt at man velger å gå over til .NET. Hva heter konseptene og mekanismene som brukes i .NET, hvordan kommer jeg meg i gang... kort sagt: hvilke stikkord trenger jeg å lese meg opp på? .NET omfatter et digert begrepsapparat som er direkte avskrekkende for nybegynnere, så det hadde vært greit å få snevret inn fokus littegrann.

[MailMan13]

Sett det gamle, utenom database, til side og start fra scratch om mulig.

 

Med mindre det faktisk er utviklet noenlunde ordentlig og objektorientert ville jeg ikke kastet bort tid på å migrere deler av systemet om gangen. Og hvor mange VB6-prosjekter er noe i nærheten av objektorienterte? Slike gamle løsninger er ofte veldig "prosedyrelt" kodet, og tett bundet til gamle API'er som ADODB og MSXML4.0 og den slags. Klart det går an å lage grensesnitt mot dem fra .NET også, men da taper man også mye av gevinsten av migreringen også. Et "ADODB.Recordset" er like uregjerlig om det refereres fra C# eller VB6.

 

Vi har noen slike systemer her også. Gammel VB6 kode i utgangspunktet, og forvaltning senere som legger til diverse .NET assemblies her og der med en blanding av classic asp og vbscript som konsumenter. Det blir en spagetti av dimensjoner som man aldri blir ferdig med.

 

Så, start på nytt med ny arkitektur om mulig. Brukbare kodesnutter i VB6 kan konverteres til VB.NET, resten gjenskapes. Spesielt om du ikke er veldig stødig på utvikling i .NET vil det være utfordring nok i det, uten all ballasten fra COM+/VB6.

Endret 1. mars 2010 av MailMan13

[alfred97]

Takk for svarene, folkens, men jeg føler enda at en del ting er uklare.

 

Med dagens løsning har jeg som sagt en server som består av noen komponenter av typen COM+. Disse innkapsler serverfunksjonaliteten, og deployes direkte i Component Services. Klienten knytter seg så direkte mot disse komponentene, og kaller metoder som komponentene eksponerer.

 

Det jeg egentlig lurer på er hvordan noe tilsvarende oppnås i .NET. Hvordan konstruerer man en serverkomponent som kjører og tilbyr tjenester? Må jeg bygge serveren som en exe-fil (evt. windows-service), eller har .NET en annen mekanisme for å deploye serverkode?

[GeirGrusom]

Kommer an på hva slags programvare det er snakk om... Du har services, du har DLL filer, du har vanlige programmer... Som sagt kan du også bruke COM+ i .NET (og omvendt) som gjør at du an gradvis migrere om du ønsker det.

Jeg vil tro at .NET i utgangspunktet er bedre egnet til dette enn COM+, men det avhenger selvsagt av hva slags serverprogramvare det er snakk om.

[MailMan13]

Serverkomponenter i .NET lager man helst med med Windows Communication Foundation (WCF) nå om dagen. Det er også mulig å lage windows service og kjøre RPC, eller i COM+ også for den saks skyld, men det er WCF som tilbyr mest fleksibilitet og er blitt "default goto"-løsningen for server-tjenester siden det kom med .NET 3.0

 

Hvordan man deployer en WCF tjeneste varierer utifra hvilke klienter og miljø man har med å gjøre. I utgangspunktet kan man bruke alt fra "gammeldags" SOAP Web Service til named pipes om klient og server kjører på samme maskin. Tjenestene hostes enten i sin egen prosess som windows service, eller i IIS etter preferanse.

 

Det er litt uklart for meg hvordan arkitekturen din er. Kjører du et felles servicelag som flere klienter kobler seg til (DCOM), eller har du en installasjon hvor hver klient har sitt eget servicelag lokalt på maskinen?

 

Hvis det er lokoalt legger du forretningslaget i et eget assembly og linker det inn, slik at det blir en egen .dll i output. Hvis det er en erstatning for DCOM bør du lage et servicelag som eksponerer WCF-tjenester.

Endret 2. mars 2010 av MailMan13