OOP genbrug
Softwarekomponenter i .NET er selvbeskrivende. Du kan spørge enhver stump program, hvilke objektklasser det består af, hvilken version det er og om andre informationer.
Dette er den anden artikel om teknologien i .NET fra Microsoft. Den første artikel Sådan virker Microsofts .NET-teknologi introducerede runtime-motoren i .NET: CLR. Vi beskrev, at alt i .NET er objektorienteret, hvilket også gælder de simpleste datatyper. Denne velkendte ide bliver systematisk sat i produktion i .NET-teknologien.
Microsoft har udviklet komponentmodellen i .NET i forhold til COM (Component Object Model) ved blandt andet at putte metadata ind i komponenterne, som gør komponenterne nemmere at styre og organisere. Softwarekomponenterne er selvbeskrivende, også under programkørsel (runtime). Det løser en række problemer, som vi starter med at introducere.
Genbrug giver meget store programmer
Objektorienteret programmering (OOP) blev populært for mange år siden, blandt andet fordi det kunne bruges til at bygge videre på andres programkode. Ved at programmere objektklasser ovenpå eksisterende klasser og objekter, kunne programmører hurtigt skrive applikationer, der udnyttede andres arbejde. Programkode til håndtering af tekststrenge, filer, vinduer, menuer og meget andet kunne arves fra andre og bruges umiddelbart.
For mange udviklere til pc-platformen blev den første erfaring med OOP dog blandet. Nok blev der sparet meget tid på dette genbrug. På den anden side kunne et lille program på nogle hundrede kilobyte, som blev omskrevet med objektorienteret genbrug af andres programkode, pludselig vokse til en størrelse på mange megabytes. Genbruget af programkode med OOP gav voldsom vækst i programmernes omfang.
Uoverskueligt
Uoverskuelige programmer
Med indførelsen af grafisk brugerinterface voksede programmerne i omfang. Men væksten skyldtes også, at det var ugennemskueligt, hvad der blev importeret af kode i programmet med genbrug af klasser og objekter. Disse klasser og objekter fra andre benyttede nemlig sig på side af en masse andre objekter, som dermed kom med ind i det endelige program.
Der findes flere strategier til at håndtere dette problem. Programmører, der arbejder med RAD (Rapid application development) i for eksempel Visual Basic, kan umiddelbart vælge ikke gør noget ved det. Programmerne bliver distribueret på cd-rom, der har plads nok, og brugerne opgraderer pc'erne. Som modsætning til den strategi finder vi en systematisk gennemskrivning af programmerne for at fjerne overflødig programkode. For eksempel kan C++-programmører optimere programmerne til maximal hastighed og minimal størrelse. Dele af programmet kan omskrives i ren C, eller det optimeres med indlejrede assembler programmer. Det er en teknisk optimal løsning, men den er er også meget kostbar i programmørtid.
Mange softwareprodukter gennemlever gennem tiden et livsforløb fra den første version til stabile versioner, som slutter med de sidste reviderede versioner. Derefter forsvinder programmet fra markedet. De gode produkter bliver i tidens løb revideret i flere versioner. Programmørerne skal overskue denne situation, hvor den nyeste version af et program er en opdatering af et rettet program fra en opdateret version af en fejlrettet version af kildeteksten til det, der engang var et godt program. Styring af disse programversioner er afgørende for at udvikle stabile programmer.
Med mange rettelser og versioner bliver programmerne uoverskueligt, og det er ikke til at gennemskue andres arbejde. Microsofts Common Object Model, COM gav programmører adgang til andres moduler, men modellen gav ikke indsigt i, hvordan funktionerne var implementeret .
Disse problemer kan løses i .NET, men først skal vi vise, at systemadministratorer har tilsvarende problemer.
DLL-hell
Brugernes overblik
For brugerne og systemadministratorerne er det i dag Windows styresystemet, som administrerer softwarekomponenterne. Der installeres forskellige programfiler, der blandt andet omfatter DLL-filer, DLL betyder dynamic link library. DLL-filerne er små programmer eller softwarekomponenter, der kan deles af mange Windows applikationer. Via en registreringsdatabase styrer Windows de installerede programmer, og DLL-filer registreres i registreringsdatabasen.
Når brugerne installerer nye og gamle programmer, sletter nogle programmer og installerer flere nye, som de måske henter fra Internet for at prøve dem, da ender det til sidst med, at Windows ikke kan styre programmodulerne. Vi når en situation, som kaldes "DLL-hell". DLL-helvedet er situationen, hvor Windows ikke længere har styr på hvilke moduler, der skal bruges.
Det ene program kan ødelægge styringen af programmoduler, som et andet program skal bruge. Når du afinstallerer et gammelt program, risikerer du, at det sletter en DLL-fil, som skulle bruges af et af dine nye og nødvendige programmer. Brugerne ser typisk problemet i form af sådan en fejlmeddelelse her:
Det går hårdest til blandt eksperimenterende brugere, der installerer demonstrationssoftware i et væk, downloader og kører programmer fra Internet, installerer gamle og nye versioner på skift. Windows magter ikke at holdes styr på den flod af moduler, som kommer ind.
Det store flertal af brugere kan ikke bruge denne meddelelse til noget. Mange gange resulterer det i, at al software skal installeres forfra - eventuelt også selve Windows styresystemet. Det er dyrt i tid.
Der findes i dag er flere strategier til at modgå problemet:
Microsoft har til Visual Studio version 6 en såkaldt installer, der kan styre installationen af nye programmer. Den sidste version af programmet kan håndtere flere versioner af samme DLL'er på pc'en.
Mange systemadministratorer fastfryser Windows-installationer. Det vil sige, der er udarbejdet en standard installation med Windows, Office software og andre nødvendige værktøjer. Og alt andet er bandlyst. Det er en nødvendig politik, når der skal administreres hundreder af pc'er, der skal holdes kørende med en minimal indsats af tid. IT-afdelingen tager kun ansvar for standardinstallationen, og der bruges ikke tid på andet.
Denne løsning sikrer ligesom ovenstående, at pc'ernes installation er intakt, fordi programmerne hurtigt kan geninstalleres.
Men med udsigt til fremtidens dynamiske Internet-pc-brugere, da skal Microsoft spille op mod den situation, hvor Windows pc'en skal afvikle utallige programmer, som kommer og går.
Selvbesskrivende
Farvel til DLL-hell - versionsstyring
Budskabet blev sagt flere gange på Visual Studio .NET konferencen for udviklere: Det såkaldte DLL-helvede er slut med .NET. Med .NET bliver versionsstyring af softwarekomponenter understøttet af systemets kerne og lagt ind i komponenterne. Og her kan der anvendes flere sideløbende versioner af samme softwarekomponter samtidig.
.NET reducerer opgaven med at holde orden på alle softwarekomponenterne for Windows, fordi komponenterne bliver selvstyrende. Windows registreringsdatabase er væk.
Du kan klikke på ethvert element i programmet og kildekoden og spørge: Hvad er det? Svaret er objektklassen med navn, hvilke funktioner der kan udføres på den pågældende samt hvilke afhængigheder, som pågældene objekt har til andre moduler. Det kan gøres med visuelle værktøjer og på tværs af programmeringssprog i hele Visual Studio .NET miljøet.
Selvbeskrivende objekter
.NET løser problemerne ved, at alle objekter er selvbeskrivende. Uden brug af andre filer kan alle softwarekomponenter præsentere sig selv, sine datatyper og afhængigheder til andre komponenter. Denne beskrivelse ligger som metadata, hvilket er supplerende informationer om objekterne. Disse oplysninger pakkes sammen med objekternes programkode.
Metadata-informationerne om klassen, dens egenskaber, begivenheder og andet kan formidles med det Microsoft kalder "reflection," hvormed CLR (common language runtime) ved programkørsel viser objekternes type, egenskaber, metoder, konstruktorer, data og adgangs niveauer. Det er altså ikke oplysninger, der er forbeholdt programmørerne i deres udviklingsmiljø. Systemadministratorer kan også bruge disse informationer, når programmerne kører på maskinen.
Microsoft .NET bruger begrebet en "assembly" som navn for den samlede enhed med ressourcer, typer og metadata om dem. Selve metadataene i komponenterne under .NET, kalder Microsoft "assembly manifest", og den inkluderer information med lister af typer og ressourcer for ekstern anvendelse. Manifest'et indeholder også information om afhængigheder, sådan som version og dato for assembly'ens bygning.
Udviklerne kan specificere en versionsstyring, som under kørsel af programmet kan styre, hvilken version af en komponent, der skal bruges. Det kan være en specifik version eller den nyeste version. For eksempel kan programmøren indbygge informationer til printermodulet, at dette er specifikt knyttet til Word version 2000.
Sikkerhed
Sikkerhed kan indbygget i softwarekomponenterne
Versionsstyring af softwarekomponenter er kun en af flere egenskaber, som udviklerne kan indbygge i softwarekomponenterne med .NET-teknologien. Visual Studio .NET giver også programmørerne mulighed for hurtigt og nemt at indlægge kryptering og signaturer direkte i de enkelte komponenter. Dermed kan de give dem en digital signatur, eller betinge at brugerne har en krypteringsnøgle, før programmodulerne kan køres på maskinen.
Alt i alt understøtter Visual Studio .NET udvikling af softwarekomponenter, der har en passende størrelse, så de kan distribueres fleksibelt over Internet. Det giver komponenter, der kan installeres dynamisk og kontroleret med versionsstyring, uden Windows skal forsøge at administrere det. Deruden får udviklerne mulighed for at indbygge digitale signaturer, som kan anvendes til at give brugere en garanti fra leverandøren på, at der ikke er virus i programmerne. LIgesom komponenterne kan få indbygget adgangskontrol med kryptering, så kun kunder med nøgle kan bruge dem.
Til slut skal vi nævne det, som er Microsofts velkendte klassiske styrke. Det hele udvikles med et grafisk visuelt brugergrænseflade, hvor Visual Studio giver programmører mulighed for at bygge programmer med peg og klik på skærmen, eller de kan skrive programkode i en klassisk editor. Samtidig giver Visual Studio overblik over objektklasserne og deres egenskaber.
I næste artikel ser vi på .NET og programmeringssprogene.
