Sourcecode: DotNet i et nøtteskall

[Hawkie]

DotNet i et nøtteskall

Med introduksjonen av Microsoft's DotNet teknologi var det mange røster som hevet seg og sa at vi når var i ferd med å vikles tettere inn i en Microsoft styrt verden, men er det blitt slik?

 

Les artikkelen her

[Coq Rouge]

Har bare et par spørsmål angående artikkelen.

 

"[..] Java er avhengig av at klienten laster ned komponentene og de kjøres på klientsiden, så kjøres DotNet elementer på server siden og leveres til klienten som ren HTML(for websider) eller som en ren plattform applikasjon."

 

Såvidt meg bekjent har man flere varianter av java..... blandt annet muligheten til å kjøre det som serverplugin (Servlets) på lik linje med ASP og PHP slik at det kun produserer HTML som output. Og med ".... ren platform applikasjon...." vil jeg anta at du mener at det enten lastes ned noe til klienten slik at denne kan kjøre programmet lokalt (i likehet med java applets). I tilfelle er jo den største forskjellen mellom det at de er identisk like.....

 

På server siden er det kanskje at man oppdager hvor mye DotNet har å tilføre. Styrken i DotNet ligger her på dens mulighet for multiserver støtte, samt pre-compile av applikasjonene. Sammenlignet med PHP er DotNet applikasjoner noe bedre til å tåle store belastninger.

 

En har muligheten til å precompile PHP også.... dette koster vel og merke penger, men har du en viktignok aplikasjon er ikke akkurat det noe problem regner jeg med..... veldig få som egentlig drar noen enorm fordel av prekompilering... Denne prekompilatoren er utviklet av selskapet som også utvikler PHP parseren, og kan finnes her: Zend Accelrator

 

Coq Rouge (.NET er også veldig mye utenom VB og ASP. Ta C# for eksempel)

[MailMan13]

Det som overrasket mange var at når Microsoft og Sun endte opp i en diskusjon om Microsofts egen Java Virtual Machine og Sun dro tilbake lisensen til å bruke Java for Microsoft.

Sun har alltid arbeidet for å få M$ til å fjerne kvasi JVM'et som gikk ut på dato i '99 fra IE, M$ har heller aldri hatt lisens på Java siden spesifikasjonen er åpen og M$ laget sin egen implementasjon. Microsoft fjernet den fordi de lå an til å tape et milliardsøksmål fra Sun for å ha sabotert Java-plattformen på klientsiden ved å distribuere inkompatible utdaterte JVM til 97% av nettbrukerene (IE brukere).

 

så kjøres DotNet elementer på server siden og leveres til klienten som ren HTML(for websider) eller som en ren plattform applikasjon.

Det er det akkurat det J2EE gjør.

 

Skal man dra en sammenligning må man ihvertfall vite hva begge platformene er

[alftore]

En ting jeg synes er spesielt kjipt med java vs .net er det grafiske i java.

Alltid et utrolig styr å få plassert de grafiske komponentene i java og det tar dermed altfor lang tid å bygge opp et GUI. Finnes riktignok programmer som kan hjelpe deg med dette, men de er etter min erfaring ofte buggy og genererer ofte mye og en del unødvendig kode.

 

I tillegg er Swing utrolig treigt. har du et litt avansert grafisk program er det som sirup. Dette kan løses med å bruke SWT som bruker native widgets, dvs samme komponenter som operativsystemet. Det at GUI skal se likt ut i alle OS er greit nok, men ofte unødvendig.

[MailMan13]

En ting jeg synes er spesielt kjipt med java vs .net er det grafiske i java.

Alltid et utrolig styr å få plassert de grafiske komponentene i java og det tar dermed altfor lang tid å bygge opp et GUI.

Det er fordi du har kodet for lite GUI i java, det finnes Absolute layout og verktøy som lag deg lage GUI på akkurat samme måte som man gjør i .NET studio. (f.eks Sun ONE Studio og Borland JBuilder.) Sun ONE Studio lager bedre kode enn jeg klarer å skrive selv.

 

Nå kjenner ikke jeg .NET så godt, men jeg fra java at AbsoluteLayout klassen stort sett bare brukes til prototyping, rett og slett fordi statisk plassering ikke er godt nok når man lager grensesnitt som skal brukes av noen. Forandrer brukeren sin look n' feel slik at man får andre størrelser på fonter og widgets faller designet igjennom, skal brukeren kunne forandre størrelsen på et vindu må layout følge med osv... Jeg er ganske sikker på at det finnes akkurat de samme layout manager implementasjonene i .NET, en eller annen form for dynamisk layout må det være for å i det heletatt skal kunne brukes til noe.

 

Ellers er jeg enig i at SWING er for treigt, det virker som grafiske klientprogrammer har vært ute av fokus litt for lenge hos Sun.

Endret 19. februar 2004 av MailMan13

[alftore]

I .NET har du muligheten til å låse (anchor) komponenten mot en eller flere av sidene til vinduet. Låser du den mot høyre og bunn vil den konsekvent holde den samme avstanden til disse sidene når vinduet endrer størrelse. Samtidig har du også mulig til å si at komponenten skal fylle vinduet i forskjellige områder.

[fjotten]

Diskusjonen kommer kanskje litt vekk fra temaet nå men... Et annet problem med Swing er at det blir litt "annerledes" enn resten av desktopen. Her er også SWT en forbedring. Men da ser det jo som sagt ikke likt ut på alle plattformer.

[Hawkie]

Poenget med artikkelen var vel ikke å diskutere hverken for eller imot noen teknologier, men heller å dra noen gjenkjennbare sammeligninger.

 

Når det gjelder en referanse til J2EE og storskala applikasjoner her, så kan jeg jo nevne at telenormobil's websider gikk på en J2EE motor frem til oktober når de måtte skifte. grunnen til at de måtte skifte var rett og slett at J2EE applikasjonene ikke tålte det volumet som de hadde. Nå kjører telenormobil DotNet sider som en av de første i stor skala i Norge, og jeg kan nevne at responsen (personlig som bruker av websidene) er mye raskere nå enn før.

 

Når det gjelder PHP så er det en løsning som jeg har en forkjærlighet for selv, men om man skal kunne være profesjonell så må man innse når noe har en begrensning, og PHP har desverre et meget stort forbruk av server minne ved mange requests, og er desverre meget enkelt å ta ned med et DoS angrep.

 

Det som er nytt med Dotnet er egentlig hvor fort de som prøver DotNet har falt for det, og porteringen inn i andre applikasjonsmiljøer viser at selve grunn ideen er meget godt uttenkt.

 

Java kan prekompileres også, men stordelen av java applikasjoner er applets som krever bruker nedlasting og derved blir tyngre å kjøre. Javascript må IKKE misforstås med Java, like som ikke VBScript må misforstås med ASP eller DotNet.

 

Det som er spennende er hvor godt DotNet teknologien er tilpasset å støtte åpne standarder. Her er det lagt inn meget god støtte for å bruke XML som lagringsmetode av data, noe som igjen gjør portering og presentasjon til en sak som kan gjøres på kryss og tvers av applikasjons motorene.

 

Mailman13 siterte meg også når det gjelder MS og utskiftningen av MSJVM, men helt uten å ta med hele meningen. Han glemmer at det mitt sitat gjaldt var jo det faktum at med sin markedsmakt kunne MS meget lettvint ha faset ut all Java støtte og derved lagt Java mer eller mindre død. At de ble presset var jo ikke noe som er relevant i selve valget deres med å fortsette med Java engine støtte i kjernen på sin IE. Alle som programmerer vet hvor enkelt det er å blokkere for en teknologi i en applikasjon, så i dette tilfellet var det oppsiktsvekkende at MS ikke ville fase ut Java til fordel for DotNet. Ikke glem at inn i Dotnet teknologien er også lagt inn Visual Java, noe som burde bety noe. Her kan man med andre ord binde sammen applikasjoner med Java, VB, C# under en samlet applikasjons plattform. Kunnskapsmessig betyr det at man kan blande kompetanse i team og nyte godt av hver enkelts foretrukne programmerings plattform.

Endret 21. februar 2004 av Hawkie

[MailMan13]

Java kan prekompileres også, men stordelen av java applikasjoner er applets som krever bruker nedlasting og derved blir tyngre å kjøre.

Hvor har du det ifra? Jeg kjenner bare til en håndfull steder der man aktivt bruker java applets. Hvis man ser på antall applikasjoner som er i produksjon er det svært få som bruker applets til noe som helst. Og når en gjennomsnittlig klient har >1GHz prosessor så kan det jo faktisk være svært gunstig å flytte, spesielt tallknusing, over på klienten. Brukt riktig er en applet et svært nyttig hjelpemiddel. Brukt feil (som de ofte er) blir de en flaskehals og kilde til inkompabilitet. Å sammenligne Java applets med serverside programmering av typen .NET med ASP blir som å sammenligne epler og bananer, eller kanskje mer som å sammenligne en moped og en lastebil de er ikke ment å dekke samme behov.

 

Han glemmer at det mitt sitat gjaldt var jo det faktum at med sin markedsmakt kunne MS meget lettvint ha faset ut all Java støtte og derved lagt Java mer eller mindre død.

Alle som har prøvd å skrive en applet mot Java 1.1.3 og AWT (som kom i 98, den gang java var ment for brødristere og mikrobølgeovner) vet hvor ubruklig disse er, det er ikke uten grunn man kaller det "Awful Windowing Toolkit". MSJVM tvang utviklere som ønsket å bruke applets til å bruke 4-5 år gammel teknologi rett og slett fordi det var det MS hadde pakket på 97% av verdens nettbrukere (altså, ved hjelp av sin markedskraft). Hadde Sun kunnet tilby et JVM som en tredjeparts plugin på samme måten som f.eks Macromedia tilbyr Flash hadde nok bruken av applets vert mer til å leve med. Så ja, Microsoft brukte sin markedskraft mot Sun ved å tilby teknologi som var halvferdig, tillagt egene utvidelser, bare delvis kompatibel og ved å holde fast på dette lenge etter Sun hadde gitt ut langt bedre utgaver (det er milevis mellom Java 1.4 med Swing og Java 1.3/AWT, som å sammenligne VB.NET og VB 4.0).

 

Av standerder er det liten forskjell på de to, eneste måtte være at MS tviholder på DCOM for distribuerte objekter mens resten av verden bruker Corba/IIOP. Med voksende bruk av WebServices og XML blir det mindre og mindre aktuelt å sammenligne plattformer og språk siden alle kan leve sammen i fredfull harmoni uansett hvilket språk de er skrevet i.

 

Når det gjelder en referanse til J2EE og storskala applikasjoner her, så kan jeg jo nevne at telenormobil's websider gikk på en J2EE motor frem til oktober når de måtte skifte. grunnen til at de måtte skifte var rett og slett at J2EE applikasjonene ikke tålte det volumet som de hadde.

Det har nok mer med måten deres programvare er implementert på enn potensialet til teknologien. Det er f.eks vanskelig å skille Oracle 9i App Server (J2EE) fra .NET på ytelse. Det er jo klart at man må ta flere hensyn når man velger en J2EE container siden det finnes såpass mange der ute og alle kan umulig være like gode på alt. .NET er man jo i praksis låst MS sin implementasjon (finnes det flere i 'final' versjoner?) så da vet man hva man får, det kan jo være en fordel det også.

 

Det som er nytt med Dotnet er egentlig hvor fort de som prøver DotNet har falt for det

Hvis man kommer fra gammel VB 6.0 og ASP eller kanskje et programmeringspråk uten noe særlig rammeverk som C++ så det jo klart at en hvlike som helst ordentlig enterprise plattform er som å komme til himmelen i forhold. En ting M$ skal ha honør for er et glimrende IDE i Visual Studio som det er lett å like for utviklere.

 

Selv kan jeg java best, men også litt VB.NET, og etter mine erfaringer er plattformene mer like enn ulike. (Hvis man klarer å leve uten entitetsbønner da, det er kanskje ikke lett for en som trodde SQL i programkode var gått ut på dato , eller kanskje det er jeg som ikke har oppdaget noe i .NET)

 

Det er ikke meningen å være for anti-MS, men jeg syns artikkelen var litt for ensidig pro .NET og drar sammenligninger uten å gjøre rede for forutsetningene. Og faktiske feil som:

...Java er avhengig av at klienten laster ned komponentene...

vitner om at artikkelforfatteren ikke vet hva Javaplattformen egentlig er.

Endret 22. februar 2004 av MailMan13

[tarpoon]

Tittelen på artikkelen svarer ikke til innholdet i det hele tatt. Mer riktig tittel ville vært ".NET webprogrammering i et nøtteskall", da innholdet bare tar for seg en liten del av .NET.

 

Ulempene som er verdt å nevne er jo Winforms, men en annen er at web applikasjoner som har liten trafikk bruker noe mer minne og ressurser på lav belastning.

 

Forstår ikke helt hvorfor winforms plutselig blir trukket inn her som en ulempe? Er det ikke snakk om webutvikling her?

 

Web applikasjonene kan støttes av alle weblesere med lik presentasjon av innholdet

 

Slik er det all serverside scripting, uansett om det er .NET, java, php, perl osv. Klientkode er fremdeles javascript, og den er ofte kompatibel mellom browsere.

 

Vil si at artikkelen er godt forsøk på en oppsummering av .NET, men kommer dessverre ikke helt i mål.

[wirrum]

Ikke glem at inn i Dotnet teknologien er også lagt inn Visual Java, noe som burde bety noe. Her kan man med andre ord binde sammen applikasjoner med Java, VB, C# under en samlet applikasjons plattform. Kunnskapsmessig betyr det at man kan blande kompetanse i team og nyte godt av hver enkelts foretrukne programmerings plattform.

 

Mange språk; en plattform, eller ett språk; mange platformer?

 

Hvorfor "språkuavhengigheten" til .NET er den tåpligste og mest overhyped egenskapen .NET? Les Historien om EiffelEigil.

Endret 23. februar 2004 av wirrum

[tarpoon]

Et firma bør selvfølgelig standardisere på et språk, det sier seg selv. Men fra og med Whidbey vil det bli en større forskjell mellom språkene, VB blir mer RAD-orientert, og vil få tilbake den etterlengtede "edit and continue" funksjonaliteten.

 

Det er veldig mange som ennå bruker VB6, og fra og med neste versjon av .NET vil helt sikkert mange av dem gå over til VB.NET.

[GeirGrusom]

[quote]Hvorfor "språkuavhengigheten" til .NET er den tåpligste og mest overhyped egenskapen .NET? Les Historien om EiffelEigil.[/quote]

Han overdriver, det er ikke sånn det fungerer.

Koden blir kompilert med noe CLR kode (Common Language Runtime)
Som er et avansert assembly språk som bruker CLR modulene (System.dll, system.windows.forms.dll o.s.v.) og som deretter blir kompilert til native code.

Det følger med en CLR debugger som viser denne koden.

Og skal du skrive flere språk i .NET tror jeg det heller vill vært slik:

En del VB, en del C++;
eller
En del C#, en del C++;
eller
en del EIFFEL, en del C++

hva ville vitsen med en del VB, en del C#, en del Eiffel være? helt bortkastet.

En .NET klasse jeg skrev i C++:
[code]
public __gc class VBPointer
{
protected:
 char *ptr;
 Boolean m_Allocated;
 Int32 m_size;
public:
 VBPointer();
 ~VBPointer();

 System::IntPtr *ToIntPtr();

 static bool op_Addition(VBPointer *me, Int32 value);  
 static bool op_Subtraction(VBPointer *me, Int32 value);  
 static bool op_Equality(VBPointer *a, VBPointer *b);
 static bool op_Inequality(VBPointer *a, VBPointer *b);
 static bool op_Increment(VBPointer *me);
 static bool op_Decrement(VBPointer *me);

 void Write(Byte value);
 void Write(Byte value[]);
 void Write(Int16 value);
 void Write(Int32 value);
 void Write(Int64 value);
 void Write(Single value);
 void Write(Double value);
 
 Byte ReadByte();
 Int16 ReadInt16();
 Int32 ReadInt32();
 Int64 ReadInt64();
 Single ReadSingle();
 Double ReadDouble();

 __property Boolean get_IsMemoryAllocated();
 __property Int32 get_Size();

 static VBPointer *AllocateMemory(Int32 size);
 static VBPointer *ReallocateMemory(VBPointer *mem, Int32 size);
 void Free();

};
[/code]

[exchange]

Hva med å skrive ne som er basert på fakta og ikke en sirup av subjektive oppfattninger som er direkte feil...

 

1. Standarisering vs låsning mot .Net Runtimen

 

det var det DotNet som oppfylte, nemlig å være i sannhet kompatibelt på tvers av plattformene

Med DotNet svekker Microsoft sitt eget markeds monopol

 

Framework spesifications + c# er standarisert. .Net runtimen er MS sin implemenstasjon av spesifikasjonene, og c# benytter et klasse bibliotetk, bcl, som er utviklet av ms.

Er kun et subset av framworket som vil være kompatibelt, og hvem vil egnetlig benytte av begrenset funksjonalitet når man får hele pakken fra microsft.

I longhorn låser microsoft sin implementasjon av framwork spesifications mot operativ systemet, og på den måten sikkrer en utvikler base mot produktet.

 

2.

Styrken i DotNet ligger her på dens mulighet for multiserver støtte, samt pre-compile av applikasjonene. Sammenlignet med PHP er DotNet applikasjoner noe bedre til å tåle store belastninger

 

For det første er php er script språk, dernest gir ikke prekompilering noen gevinst. Det viser seg at prekompilering ikke er effektivt, da minne flaten for appen blir større og jit ikke kan optimalisere kode kjøring.

 

3

Kort læretid om man har prøvd VB tidligere

 

Kort tid å lære seg selve vb.net ja, men alt er objekt orientert og rammeverket meget stort og komplekst. Læringskurven til .net er meget bratt

 

4.

Man har standarisert mesteparten av funksjonene slik at de er portable mellom en lang rekke plattformer

nei....

er få funksjoner som er "portable" til andre plattformer.

[TLZ]

Har programert litt .net(C#) en stund nå.

Kunne godt tenke meg å prøve en av linux versjonene (har snart Fedora i boks..).

Men eg vet ikke hvilken, er det mono som har kommet lengst? (alle klassene ikke bare asp.net)...

 

God artikkel forresten, men ASP.NET i et nøtteskal hadde vært en mer passende tittel...

 

 

Kort tid å lære seg selve vb.net ja, men alt er objekt orientert og rammeverket meget stort og komplekst. Læringskurven til .net er meget bratt

.net klassene er en ting, men har man programert VB så er det relativt lett å komme igang. Man trenger jo ikke kunnn HELE .net klassene for å kunne programere .net. Dessuten så har VB en del alias for diverse rutiner og kommandoer som gjør ting enklere. .NET er et genialt konsept, til og med en del linux-folk har "innrømmet" dette.

Endret 7. april 2004 av TLZ