mboost-dp1
unknown
Er der en der hurtigt kan forklarer mig hvad .net platformen er...?
Har altid troet at en "platform" var eksempelvis et styresystem, f.eks Windows...
Har altid troet at en "platform" var eksempelvis et styresystem, f.eks Windows...
Sakset fra
http://docs.msdnaa.net/ark/Webfiles/glossary.htm
"
.NET Framework
The .NET Framework is an environment for building, deploying, and running XML Web services and other applications. It consists of three main parts: the Common Language Runtime, the Framework classes, and ASP.NET. A companion infrastructure, the .NET Compact Framework, is a set of programming interfaces that enable developers to target mobile devices like smart phones and PDAs.
.NET platform:
The .NET platform is a set of development tools and operational systems to build, expose, and consume XML Web services, enabling a personal, integrated Web delivered through smart devices. It has four components:
.NET Framework and Visual Studio.NET,
server infrastructure,
building block services,
software for smart devices.
"
:)
http://docs.msdnaa.net/ark/Webfiles/glossary.htm
"
.NET Framework
The .NET Framework is an environment for building, deploying, and running XML Web services and other applications. It consists of three main parts: the Common Language Runtime, the Framework classes, and ASP.NET. A companion infrastructure, the .NET Compact Framework, is a set of programming interfaces that enable developers to target mobile devices like smart phones and PDAs.
.NET platform:
The .NET platform is a set of development tools and operational systems to build, expose, and consume XML Web services, enabling a personal, integrated Web delivered through smart devices. It has four components:
.NET Framework and Visual Studio.NET,
server infrastructure,
building block services,
software for smart devices.
"
:)
Jeg ser frem til den dag hvor en .NET applikation ville kunne køre på andre operativ systemer end lige Windows.
Det ville være lækkert at kunne lave programmer der var OS uafhængige, så ens operativ system ikke begrænsede hvilke programmer man kunne køre.
Mono til Linux er godt på vej, men mangler så vidt jeg ved stadig en del for at have alle de features der findes i .NET til Windows.
Det ville være lækkert at kunne lave programmer der var OS uafhængige, så ens operativ system ikke begrænsede hvilke programmer man kunne køre.
Mono til Linux er godt på vej, men mangler så vidt jeg ved stadig en del for at have alle de features der findes i .NET til Windows.
Eller for at forklare det til den almene bruger:
.NET er et ord der dækker over nogle forskellige programmeringssprog/tekonologier som Microsoft har udviklet. Det "smarte" ved .NET er at det er nemt at gå til, og det kører bedre end Java på Windows.
.NET er kun udviklet til windows, og hvis man spørger mig om dens success, så er svaret at det er microsoft. ASP er et forfærdeligt sprog at lave enterprise hjemmesider i, men det afholder ikke folk fra at gøre det - og da MS blev forbudt at sende deres egen JVM med til windows måtte de finde på noget andet - og tada - der kom .NET -> .NET er meget ligesom java, bortset fra at det ikke er designet til at være cross-platform (dog er der nogle fra OSS miljøet der forsøger at porte det under navnet "Mono").
Men ikke desto mindre er .NET en nem "platform" at udvikle på. Det er meget hurtigt at få et program op at stå, og man skal ikke tænke på memory-håndtering, og GUI kan laves via et IDE (en GUI til at designe GUIer)
.NET er et ord der dækker over nogle forskellige programmeringssprog/tekonologier som Microsoft har udviklet. Det "smarte" ved .NET er at det er nemt at gå til, og det kører bedre end Java på Windows.
.NET er kun udviklet til windows, og hvis man spørger mig om dens success, så er svaret at det er microsoft. ASP er et forfærdeligt sprog at lave enterprise hjemmesider i, men det afholder ikke folk fra at gøre det - og da MS blev forbudt at sende deres egen JVM med til windows måtte de finde på noget andet - og tada - der kom .NET -> .NET er meget ligesom java, bortset fra at det ikke er designet til at være cross-platform (dog er der nogle fra OSS miljøet der forsøger at porte det under navnet "Mono").
Men ikke desto mindre er .NET en nem "platform" at udvikle på. Det er meget hurtigt at få et program op at stå, og man skal ikke tænke på memory-håndtering, og GUI kan laves via et IDE (en GUI til at designe GUIer)
Lidt fesen undersøgelse - .Net kannibaliserer jo blot win32 udviklingen - og det kommer vel ikke som en overraskelse for nogen som helst!
Det mest overraskende i mine øjne er at java rent faktisk tager markedsandele samlet set, og at windows specifik udvikling falder.
#4:
At man ikke skal tænke på memory håndtering er vist kun i den idelle verden - .Net garbagecollectoren er ikke særlig fantastisk i en hel del tilfælde. :/
Det mest overraskende i mine øjne er at java rent faktisk tager markedsandele samlet set, og at windows specifik udvikling falder.
#4:
At man ikke skal tænke på memory håndtering er vist kun i den idelle verden - .Net garbagecollectoren er ikke særlig fantastisk i en hel del tilfælde. :/
#4
" som Microsoft har udviklet. "
njae der er nu mange .NET sprog som microsoft ikke selv har udviklet:
http://www.dotnetpowered.com/languages.aspx
" som Microsoft har udviklet. "
njae der er nu mange .NET sprog som microsoft ikke selv har udviklet:
http://www.dotnetpowered.com/languages.aspx
#6
Hvis man kan finde ud af at skrive ordenlig kode så er garbagecollecteren fantatisk nok. Det er klart at det ikke skal være en sovepude til at skrive dårlig kode på. Det er generelt ikke nogen god idé at lukke øjnene og håbe at det klare GC nok, det er jo slet heller ikke det MS råder folk til.
Hvis man kan finde ud af at skrive ordenlig kode så er garbagecollecteren fantatisk nok. Det er klart at det ikke skal være en sovepude til at skrive dårlig kode på. Det er generelt ikke nogen god idé at lukke øjnene og håbe at det klare GC nok, det er jo slet heller ikke det MS råder folk til.
#12
Det er programmører under Novell, der udvikler det (efter de købte Ximian) og det er Novell der har rettighederne på navnet etc. Tro ikke at open source altid betyder, at et gigantisk fællesskab af programmører hele verden over udvikler på det samme projekt. Det betyder blot, at alle folk kan få lov at kigge på kildekoden, hvis de har lyst.
Det er programmører under Novell, der udvikler det (efter de købte Ximian) og det er Novell der har rettighederne på navnet etc. Tro ikke at open source altid betyder, at et gigantisk fællesskab af programmører hele verden over udvikler på det samme projekt. Det betyder blot, at alle folk kan få lov at kigge på kildekoden, hvis de har lyst.
.NET er nyere og bygger på erfaringer fra Java, hvilket er grunden til at .NET er nemmere og mere konsistent. Jeg kan godt forstå at .NET vil overtage og må sige det til dels er Sun's egen skyld, de skulle have åbnet standarden og ryddet op i de bloatede, deprecatede libraries.
Da .Net er optimeret til MSSQL og IIS, vil vi formentlig også se en stigning i brugen af disse.
Jeg er lige startet med .Net og som jeg kan se det, skiller .Net sig kun markant ud med ADO.NET og ASP.NET. Endvidere er det jo rart at man selv kan vælge hvilket sprog man vil bruge.
Ellers er der jo ikke de store forskelle til eksempelvis java.
Og hvis man snakker platforms uafhængighed, så er Java jo heller ikke perfekt. Efter min mening er det eneste virkelige platformsuafhængighed http, hvilket .net prøver at gøre let med ASP.NET.
Så kadot(?) til microsoft for det.
Iøvrigt er mono udkommet i 1.0
Jeg er lige startet med .Net og som jeg kan se det, skiller .Net sig kun markant ud med ADO.NET og ASP.NET. Endvidere er det jo rart at man selv kan vælge hvilket sprog man vil bruge.
Ellers er der jo ikke de store forskelle til eksempelvis java.
Og hvis man snakker platforms uafhængighed, så er Java jo heller ikke perfekt. Efter min mening er det eneste virkelige platformsuafhængighed http, hvilket .net prøver at gøre let med ASP.NET.
Så kadot(?) til microsoft for det.
Iøvrigt er mono udkommet i 1.0
ADO.NET er faktisk små-genialt. Er der nogen der ved, om det er første gang man arbejder med en in-memory repræsentation af databaser?
Disky:
Det skulle efter sigende køre ganske fint, men har ikke selv erfaring med det.
#18:
Sludder! .Net er i princippet fuldstændig ligeglad med databasen/webserveren - der er ikke nogen hemmelige optimeringer der gør det til en fordel at bruge MSSQL/IIS(Jeg basher gerne MS, men ikke når der ikke er grund til det).
Og når du siger http, tror jeg du mener html, og til det kan jeg kun sige at ASP.Net 1.1 gør et forfærdeligt job.
Eksempelvis nægter .Net at smide width style ud når man er andet end IE, hvis man sætter width propertyen på sin kontrol - hvilket resulterer i at det meste ser forfærdeligt ud i Gecko baserede browsere. Istedet bliver man nødt til at manipulere stylen direkte.
Men heldigvis har de MEGET kritik af den beslutning, og det ser ud som om ASP.Net 2.0 klarer opgaven langt bedre!
Det skulle efter sigende køre ganske fint, men har ikke selv erfaring med det.
#18:
Sludder! .Net er i princippet fuldstændig ligeglad med databasen/webserveren - der er ikke nogen hemmelige optimeringer der gør det til en fordel at bruge MSSQL/IIS(Jeg basher gerne MS, men ikke når der ikke er grund til det).
Og når du siger http, tror jeg du mener html, og til det kan jeg kun sige at ASP.Net 1.1 gør et forfærdeligt job.
Eksempelvis nægter .Net at smide width style ud når man er andet end IE, hvis man sætter width propertyen på sin kontrol - hvilket resulterer i at det meste ser forfærdeligt ud i Gecko baserede browsere. Istedet bliver man nødt til at manipulere stylen direkte.
Men heldigvis har de MEGET kritik af den beslutning, og det ser ud som om ASP.Net 2.0 klarer opgaven langt bedre!
.NET er til grin.. Hvorfor? Jo bl.a. fordi MS deffinere paltform uafhængighed som win98, win2k og winxp, og måske en gang CE..
.NET er for stort og besværligt til mange ting, desuden, er det meget svært at holde styr på hvad der sker. Da man ikke kan se al kode.
.NET opfinder nye metoder at gøre tingene på, hvorfor er SQL ikke godt nok? Jeg ved godt at man kan bruge SQL i .NET.
Desuden markedføres .NET som et "hvermands programmeringssprog" Hvorfor skal alle nu til at kunne kode? Vil vi så ikke bare, lige som IT boomet i 90erne, hvor alle skulle lave computere og netværk, se en gang markværk i kodning og "udvikling" ??
Personligt ser jeg .NET som et forsøg fra MS side af, for at udmanøvrere JAVA :(
.NEt dur heller ikke til ret meget, taler man embedded, tja. så er .NET nok en smule for tungt. Der findes kun C og assembler :) (Nok ikke helt korrekt)
.NET er for stort og besværligt til mange ting, desuden, er det meget svært at holde styr på hvad der sker. Da man ikke kan se al kode.
.NET opfinder nye metoder at gøre tingene på, hvorfor er SQL ikke godt nok? Jeg ved godt at man kan bruge SQL i .NET.
Desuden markedføres .NET som et "hvermands programmeringssprog" Hvorfor skal alle nu til at kunne kode? Vil vi så ikke bare, lige som IT boomet i 90erne, hvor alle skulle lave computere og netværk, se en gang markværk i kodning og "udvikling" ??
Personligt ser jeg .NET som et forsøg fra MS side af, for at udmanøvrere JAVA :(
.NEt dur heller ikke til ret meget, taler man embedded, tja. så er .NET nok en smule for tungt. Der findes kun C og assembler :) (Nok ikke helt korrekt)
#20: Den er ikke ligeglad med databasen. Der er lavet en OleDB provider, der kan snakke OleDB protokollen. Derudover er der lavet en provider specifikt til MSSQL som performance mæssigt er optimeret en del.
Med hensyn til webserver har du ret. Det jeg mente, var at Visual Studio (udviklingsmiljø nr. 1 når det kommer til .net) er sammenkædet med IIS, for at gøre det lettere.
Men det er altså ikke for at bashe MS. Jeg ville da gøre det samme som dem. Hvorfor optimere til produkter fra andre firmaer? Det var mere en kostatering.
Med hensyn til webserver har du ret. Det jeg mente, var at Visual Studio (udviklingsmiljø nr. 1 når det kommer til .net) er sammenkædet med IIS, for at gøre det lettere.
Men det er altså ikke for at bashe MS. Jeg ville da gøre det samme som dem. Hvorfor optimere til produkter fra andre firmaer? Det var mere en kostatering.
#21:
1. Jeg har aldrig nogen sinde set MS kalde .Net platformsuafhængigt, men link gerne til et sted de gør det!
2. Hvad mener du med man ikke kan se al kode?
3. Uhmmm... Hvis du havde arbejdet med større database applikationer og prototyping af applikationer ville du selv kende svaret.
4. Skal MS lastes for skodkodere?
5. Helt korrekt .Net er en kopi af java tanken - men er der noget principelt galt i at kopiere en god ide?
6. Har du nogen som helst erfaring med at lave embedded applikationer? Nej, .Net vil ikke være løsningen i industrimaskiner, men der er mange andre embedded devices hvor .Net(og java) giver fin mening.
Og lige for at afklare een ting - jeg er personligt java/linux fanboy, men beskæftiger mig professionelt med .Net - jeg vil MEGET gerne være med til at bashe MS, men lad os forhelvede bashe dem på en saglig baggrund!
1. Jeg har aldrig nogen sinde set MS kalde .Net platformsuafhængigt, men link gerne til et sted de gør det!
2. Hvad mener du med man ikke kan se al kode?
3. Uhmmm... Hvis du havde arbejdet med større database applikationer og prototyping af applikationer ville du selv kende svaret.
4. Skal MS lastes for skodkodere?
5. Helt korrekt .Net er en kopi af java tanken - men er der noget principelt galt i at kopiere en god ide?
6. Har du nogen som helst erfaring med at lave embedded applikationer? Nej, .Net vil ikke være løsningen i industrimaskiner, men der er mange andre embedded devices hvor .Net(og java) giver fin mening.
Og lige for at afklare een ting - jeg er personligt java/linux fanboy, men beskæftiger mig professionelt med .Net - jeg vil MEGET gerne være med til at bashe MS, men lad os forhelvede bashe dem på en saglig baggrund!
#21 : Du skriver: ".NET opfinder nye metoder at gøre tingene på, hvorfor er SQL ikke godt nok? Jeg ved godt at man kan bruge SQL i .NET."
Det er da genialt det de har lavet. Som flere applikationer bliver flyttet over til webapplikationer, er det vigtigt at ikke 1.000.000 brugere opretholder en forbindelse til en database. Derfor flytter man det hele over i en in-memory repræsentation, som arbejder meget hurtigere, end en remote database. Derudover er det muligt at have mange flere brugere pr. database uden at løbe ind i performance problemer.
Det er da genialt det de har lavet. Som flere applikationer bliver flyttet over til webapplikationer, er det vigtigt at ikke 1.000.000 brugere opretholder en forbindelse til en database. Derfor flytter man det hele over i en in-memory repræsentation, som arbejder meget hurtigere, end en remote database. Derudover er det muligt at have mange flere brugere pr. database uden at løbe ind i performance problemer.
#22:
Helt enig, men det var ikke det der blev postuleret - der blev postuleret at .Net er optimeret til MSSQL.
#22:
Der er bare forskel på når du siger "Da .Net er optimeret til MSSQL og IIS" og "Derudover er der lavet en provider specifikt til MSSQL som performance mæssigt er optimeret en del."
.Net i sig selv er ikke optimeret til MSSQL - MS leverer blot en provider direkte til MSSQL - præcis som andre leverendører leverer providere til deres databaser.
Helt enig, men det var ikke det der blev postuleret - der blev postuleret at .Net er optimeret til MSSQL.
#22:
Der er bare forskel på når du siger "Da .Net er optimeret til MSSQL og IIS" og "Derudover er der lavet en provider specifikt til MSSQL som performance mæssigt er optimeret en del."
.Net i sig selv er ikke optimeret til MSSQL - MS leverer blot en provider direkte til MSSQL - præcis som andre leverendører leverer providere til deres databaser.
#21 >>
1) Det gør de bøger jeg har om .NET, så ikke noget link, desværre.
2) Der er flere ting man ikke har styr over i deres udviklinsværktøj, visse ting skal gøre i korrekt rækkefølge, ellers kan man blive tvunget til at lave det om, da man netop ikke har 100% styr over hvor tingene implementeres. Jeg er ikke den eneste med det problem.
3) SQL virker fint. Men det er så min holdning.
4) MS skal fri os fra skodkodere. Nuvel alle skal have lov til at lære det, men vi ser nok bare endnu engang, at alle vil til at slå sig på det samme. Det er ikke gået godt før, hvorfor skulle det så nu?
5) Slet ikke...
6) Ja jeg har.
ja ja mange ting er smarte i .NET, men ikke alt der skinner er af guld.
1) Det gør de bøger jeg har om .NET, så ikke noget link, desværre.
2) Der er flere ting man ikke har styr over i deres udviklinsværktøj, visse ting skal gøre i korrekt rækkefølge, ellers kan man blive tvunget til at lave det om, da man netop ikke har 100% styr over hvor tingene implementeres. Jeg er ikke den eneste med det problem.
3) SQL virker fint. Men det er så min holdning.
4) MS skal fri os fra skodkodere. Nuvel alle skal have lov til at lære det, men vi ser nok bare endnu engang, at alle vil til at slå sig på det samme. Det er ikke gået godt før, hvorfor skulle det så nu?
5) Slet ikke...
6) Ja jeg har.
ja ja mange ting er smarte i .NET, men ikke alt der skinner er af guld.
#26 ok. .Net virker performance mæssigt bedst med MSSQL, derfor kunne man forestille sig en stigning i brugen af MSSQL.
Og hvorfor tror alle at det er for svine MS. Man skal snart udtale sig enormt forsigtigt. Jeg er så træt af den religionskrig. Det virker som om at alle så gerne vil snakke linux <> Windows lige så snart, der står MS i en nyhed. *suk*
Og hvorfor tror alle at det er for svine MS. Man skal snart udtale sig enormt forsigtigt. Jeg er så træt af den religionskrig. Det virker som om at alle så gerne vil snakke linux <> Windows lige så snart, der står MS i en nyhed. *suk*
#28 >> Håber selv på der kommer noget rigtig smart og revolutionerende, som hverken er MS eller Linux.
Men desværre er tendensen hældende til at der ikke kommer ret meget smart og ret meget revolutionerende. Men det ville sgu nok også koste visse folk/firmaer for meget.
Lige en strø tanke(offtopic): For 7/8 år siden, snakkede jeg med en ven om, IT sektoren, dengang blev vi enige om, at det er trist, når det største man kan opnå, er at blive opkøbt af MS, det er det stadigvæk. Ikke for at bashe MS, jeg er selv pro MS, men man skal ikke tage alt der kommer fra dem, som var det verdens bedste...
Men desværre er tendensen hældende til at der ikke kommer ret meget smart og ret meget revolutionerende. Men det ville sgu nok også koste visse folk/firmaer for meget.
Lige en strø tanke(offtopic): For 7/8 år siden, snakkede jeg med en ven om, IT sektoren, dengang blev vi enige om, at det er trist, når det største man kan opnå, er at blive opkøbt af MS, det er det stadigvæk. Ikke for at bashe MS, jeg er selv pro MS, men man skal ikke tage alt der kommer fra dem, som var det verdens bedste...
#27:
2) Så er det deres udviklingsværktøj du har et problem med - ikke .Net! Brug smartdevelop istedet? (Ja, eksempelvis hader jeg nær VS vælger at fucke ens html-tags op hvis man er så uheldig at trykke på designeren - et problem der iøvrigt er løst i 2005! :))
3) At det virker fint for dig betyder jo ikke at det virker fint for andre - the right tool for the right job.
4) Jeg kan ikke rigtigt argumentere på det her punkt - du mener at det er producentens job at fri os fra skodkodere - det gør jeg ikke :)
6) Så du mener altså at det eneste der dur til eksempelvis udvikling på mobiltelefoner er asm og c?
2) Så er det deres udviklingsværktøj du har et problem med - ikke .Net! Brug smartdevelop istedet? (Ja, eksempelvis hader jeg nær VS vælger at fucke ens html-tags op hvis man er så uheldig at trykke på designeren - et problem der iøvrigt er løst i 2005! :))
3) At det virker fint for dig betyder jo ikke at det virker fint for andre - the right tool for the right job.
4) Jeg kan ikke rigtigt argumentere på det her punkt - du mener at det er producentens job at fri os fra skodkodere - det gør jeg ikke :)
6) Så du mener altså at det eneste der dur til eksempelvis udvikling på mobiltelefoner er asm og c?
#28
Jeg giver dig fuldstændig ret i at "MS leverer blot en provider direkte til MSSQL - præcis som andre leverendører leverer providere til deres databaser."
#NET er et af de bedste produkter fra MS.
Grundet til at #NET og MSSQL rykkger helt igennem er MSSQL er en kanon god database. Stored procedures, triggers, caching, etc. etc.
Jeg giver dig fuldstændig ret i at "MS leverer blot en provider direkte til MSSQL - præcis som andre leverendører leverer providere til deres databaser."
#NET er et af de bedste produkter fra MS.
Grundet til at #NET og MSSQL rykkger helt igennem er MSSQL er en kanon god database. Stored procedures, triggers, caching, etc. etc.
#28:
Nej! .Net virker performance mæssigt præcis ligeså godt med eksempelvis .Net connectoren til MySQL. (Dvs. at til nogen ting vil mysql være hurtigere - til andre MSSQL. Ie. MSSQL får ikke noget ekstra ved at blive kaldt fra .Net)
Og man bliver heller ikke beskyld for at svine nogen som helst hvis ens argumenter er sagligt funderede - det synes jeg ikke din originale post var! :)
Nej! .Net virker performance mæssigt præcis ligeså godt med eksempelvis .Net connectoren til MySQL. (Dvs. at til nogen ting vil mysql være hurtigere - til andre MSSQL. Ie. MSSQL får ikke noget ekstra ved at blive kaldt fra .Net)
Og man bliver heller ikke beskyld for at svine nogen som helst hvis ens argumenter er sagligt funderede - det synes jeg ikke din originale post var! :)
#30
2) Det er meget muligt det er deres udviklingsværtøj, jeg har desværre ikke adgang til 2005 udgaven.
3) Jepper det virker fint for mig. Det gør det sikkert også for andre (Oracle og lignende), men jeg kan tage fejl, jeg kan ikke, modsat alle andre brugere på newz.dk, kende til alt.
4) Ikke nødvendigvis, men nogen burde gøre det. :-)
6) Jeg mener nok at til mindre systemer, hvor der ikke er uendeligt mange resourcer at trække på, der bør man bruge et "sprog" der er mere optimalt.
Læs et John Carmacks og til en vis grad Carl Sassenrath udtalelser om samme. Men nu er mobil telefoner nok anderledes, da det er til masserne, og her skal der være spil. Så lige hvad spil til masserne angår, og mange forskellige mobiler, så skråt op med optimering, lav noget alle kan spille.
2) Det er meget muligt det er deres udviklingsværtøj, jeg har desværre ikke adgang til 2005 udgaven.
3) Jepper det virker fint for mig. Det gør det sikkert også for andre (Oracle og lignende), men jeg kan tage fejl, jeg kan ikke, modsat alle andre brugere på newz.dk, kende til alt.
4) Ikke nødvendigvis, men nogen burde gøre det. :-)
6) Jeg mener nok at til mindre systemer, hvor der ikke er uendeligt mange resourcer at trække på, der bør man bruge et "sprog" der er mere optimalt.
Læs et John Carmacks og til en vis grad Carl Sassenrath udtalelser om samme. Men nu er mobil telefoner nok anderledes, da det er til masserne, og her skal der være spil. Så lige hvad spil til masserne angår, og mange forskellige mobiler, så skråt op med optimering, lav noget alle kan spille.
#35: Det er på vej, i den nye udgave af MSSQL2005.
Se evt.:
http://download.microsoft.com/download/8/7/f/87ff3...
• Expanded language support. With the common language runtime (CLR) hosted in the database engine, developers will be able to choose from a variety of familiar languages to develop database applications, including Transact-SQL, Microsoft Visual Basic® .NET, and Microsoft Visual C#® .NET.
Se evt.:
http://download.microsoft.com/download/8/7/f/87ff3...
• Expanded language support. With the common language runtime (CLR) hosted in the database engine, developers will be able to choose from a variety of familiar languages to develop database applications, including Transact-SQL, Microsoft Visual Basic® .NET, and Microsoft Visual C#® .NET.
Hvis man ikke gider MSSQL så kan man da også bare bruge Oracle eller MySQL. Oracle db provider er også med som standard(System.Data.OracleClient) og er lige så let som mssql.
MySQL har også lavet en connector http://www.mysql.com/products/connector/net/ så der er næsten fri db valg...
MySQL har også lavet en connector http://www.mysql.com/products/connector/net/ så der er næsten fri db valg...
#23
"Derudover er der lavet en provider specifikt til MSSQL som performance mæssigt er optimeret en del."
Men synes nu at det er ulækkert at noget MS specifickt (System.Data.SqlConnection som KUN virker med MSSQL) bliver placeret i System.Data namespace, men nok bare mig...
De har jo sjovt nok et Microsoft namespace, men bruger de sjovt nok ikke i det tilfælde - synes det lugter.
#17
"Jeg kan godt forstå at .NET vil overtage og må sige det til dels er Sun's egen skyld, de skulle have åbnet standarden og ryddet op i de bloatede, deprecatede libraries."
Velkommen til den virklige verden! Man fjerner jo ikke bare lige gamle metode kald, så breaker du lige 58465798 applikationer!!
og hvad hulen mener du med at åbne en standard???
Hvis du mener at de skulle have standardiseret Java, så må du godt lige påminde Microsoft selv samme. De har heller ikke standardiseret .NET (kun CLR/IL).
I øvrigt hvis du synes at Java's API er slemt, så synes jeg du skal dykker lidt dybere i .NET. Det er tydeligt at du kun har skimmet overfladen. NET har fået en del høvl over at deres API i mange tilfælde ligner en wrapper omkring MFC og er lige lovligt "rushed".
"Derudover er der lavet en provider specifikt til MSSQL som performance mæssigt er optimeret en del."
Men synes nu at det er ulækkert at noget MS specifickt (System.Data.SqlConnection som KUN virker med MSSQL) bliver placeret i System.Data namespace, men nok bare mig...
De har jo sjovt nok et Microsoft namespace, men bruger de sjovt nok ikke i det tilfælde - synes det lugter.
#17
"Jeg kan godt forstå at .NET vil overtage og må sige det til dels er Sun's egen skyld, de skulle have åbnet standarden og ryddet op i de bloatede, deprecatede libraries."
Velkommen til den virklige verden! Man fjerner jo ikke bare lige gamle metode kald, så breaker du lige 58465798 applikationer!!
og hvad hulen mener du med at åbne en standard???
Hvis du mener at de skulle have standardiseret Java, så må du godt lige påminde Microsoft selv samme. De har heller ikke standardiseret .NET (kun CLR/IL).
I øvrigt hvis du synes at Java's API er slemt, så synes jeg du skal dykker lidt dybere i .NET. Det er tydeligt at du kun har skimmet overfladen. NET har fået en del høvl over at deres API i mange tilfælde ligner en wrapper omkring MFC og er lige lovligt "rushed".
#34:
Nejda - provideren er skrevet i .Net, så det vil ikke give mening at bruge den uden for .Net.
Men jeg skulle da mene at der er en ganske fin Delphi provider til mssql - men nu er det godt nok længe siden jeg har rørt Delphi, så jeg er absolut ikke sikker :)
#35:
Yukon(MSSQL 2005) kan køre .Net, og stored procedures kan skrives i .Net sprog.
Men jeg har ikke rigtigt rodet nok med den til at kunne sige noget nærmere :)
#38:
Ja, de kunne godt have smidt den i et Microsoft namespace - det havde været lidt mere elegant!
Nejda - provideren er skrevet i .Net, så det vil ikke give mening at bruge den uden for .Net.
Men jeg skulle da mene at der er en ganske fin Delphi provider til mssql - men nu er det godt nok længe siden jeg har rørt Delphi, så jeg er absolut ikke sikker :)
#35:
Yukon(MSSQL 2005) kan køre .Net, og stored procedures kan skrives i .Net sprog.
Men jeg har ikke rigtigt rodet nok med den til at kunne sige noget nærmere :)
#38:
Ja, de kunne godt have smidt den i et Microsoft namespace - det havde været lidt mere elegant!
Ok. Hvis provideren (som MS har optimeret performance mæssigt) er specifik til .net, så vinder man vel også noget ved at køre MSSQL i .net fremfor i et andet miljø, der ikke har en optimeret provider til MSSQL, jvf. dit indlæg: "Ie. MSSQL får ikke noget ekstra ved at blive kaldt fra .Net"
#Jammer
.NEt "gemmer" ikke kode. Hvis du bruger VS.NET og koder windows forms er der en del kode autogenereres der ikke umidlbart vises, det kan du sagtens ændre på hvis du er sur over det. Desuden er det for de fleste en god hjælp og det er slået til som default fordi mange udviklere er glade for at det bliver gjort sådan. Desuden hjælpe det i sidste ende med at få koden til at ser overskueligt ud.
Din opfattelse af at det er "forkert" at det skal blive lettere at kode undre mig lidt. Tilbage i tidernes morgen programmerede man ved at sidde manuelt og trykke huller i et hulkort for derefter at fodre det til maskinen. Eferfølgende fandt man på at bruge assembly og udvilkingen er fortsat lige siden. .NET sprogne er det sidste skud på stammen og dewt er da kun godt at det er blevet lettere at kode.
Udvikling i .NET er meget billigere end f.eks udvikling i C++ fordi det er lettere. Og den forholdsvis lille smule performance tab der er gør i langt de fleste applikation ikke nogen forskel da computere er blevet så hurtige. Og selv hvis performance er et mål så har man med .NET langt mere tid til at optimere koden fordi udviklingen går så hurtigt. Tid er penge!
Hvis ikke det var blevet lettere at kode med tiden havde vi stadig siddet og udfyldt hulkort. Tror du virkelig det ville være en god ting?
Du prøver også at få det til at lyde somom .NET er noget hø generelt, bare fordi det måske ikke lige er det bedste til at kode embeddede systemer. Det er nu engang sådan at alle ting har sine ulemper. Man kunne jo vende den om og bede dig kode en Windows applikation i assembly. Jeg har selv kodet en del i assembly men kun når det var påkrævet(interrupt handlers og sådan). Men jeg holder mig væk fra det så vidt muligt da det er ret besværligt.
Jeg har kodet i mange sprog og har kode mange forskellige ting, og .NET er efter min mening en virkelig god platform. Der er naturligvis ting det ikke er så godt til, men sådan er det jo med alt ting.
.NEt "gemmer" ikke kode. Hvis du bruger VS.NET og koder windows forms er der en del kode autogenereres der ikke umidlbart vises, det kan du sagtens ændre på hvis du er sur over det. Desuden er det for de fleste en god hjælp og det er slået til som default fordi mange udviklere er glade for at det bliver gjort sådan. Desuden hjælpe det i sidste ende med at få koden til at ser overskueligt ud.
Din opfattelse af at det er "forkert" at det skal blive lettere at kode undre mig lidt. Tilbage i tidernes morgen programmerede man ved at sidde manuelt og trykke huller i et hulkort for derefter at fodre det til maskinen. Eferfølgende fandt man på at bruge assembly og udvilkingen er fortsat lige siden. .NET sprogne er det sidste skud på stammen og dewt er da kun godt at det er blevet lettere at kode.
Udvikling i .NET er meget billigere end f.eks udvikling i C++ fordi det er lettere. Og den forholdsvis lille smule performance tab der er gør i langt de fleste applikation ikke nogen forskel da computere er blevet så hurtige. Og selv hvis performance er et mål så har man med .NET langt mere tid til at optimere koden fordi udviklingen går så hurtigt. Tid er penge!
Hvis ikke det var blevet lettere at kode med tiden havde vi stadig siddet og udfyldt hulkort. Tror du virkelig det ville være en god ting?
Du prøver også at få det til at lyde somom .NET er noget hø generelt, bare fordi det måske ikke lige er det bedste til at kode embeddede systemer. Det er nu engang sådan at alle ting har sine ulemper. Man kunne jo vende den om og bede dig kode en Windows applikation i assembly. Jeg har selv kodet en del i assembly men kun når det var påkrævet(interrupt handlers og sådan). Men jeg holder mig væk fra det så vidt muligt da det er ret besværligt.
Jeg har kodet i mange sprog og har kode mange forskellige ting, og .NET er efter min mening en virkelig god platform. Der er naturligvis ting det ikke er så godt til, men sådan er det jo med alt ting.
#41
Jeg er generelt enig med dig - men man må erkende at hvis Java og .NET er så fantastisk, er det alligevel underligt at Photoshop, Windows Longhorn, 3DSMax, Autocad osv - altså nogle ret store programmer ikke er lavet i noget VM kørende sprog.
Specielt er det kritisablet at longhorn vil være langt mere C/C++ (svjv, unmanaged) baseret end C# eller C/C++ managed - taget i betragtning af af MS vil have at alle andre skal migrerer. Dette gælder ligeledes for Java (og Solaris, eller JDS). Man venter nok på vi alle har mindst 5GHz/2GB ram :)
Men, jeg vil dog sige at *rigtigt* mange programmer kan med fordel programmeres i Java eller .NET da performance tabet er irrelevant.
Jeg er generelt enig med dig - men man må erkende at hvis Java og .NET er så fantastisk, er det alligevel underligt at Photoshop, Windows Longhorn, 3DSMax, Autocad osv - altså nogle ret store programmer ikke er lavet i noget VM kørende sprog.
Specielt er det kritisablet at longhorn vil være langt mere C/C++ (svjv, unmanaged) baseret end C# eller C/C++ managed - taget i betragtning af af MS vil have at alle andre skal migrerer. Dette gælder ligeledes for Java (og Solaris, eller JDS). Man venter nok på vi alle har mindst 5GHz/2GB ram :)
Men, jeg vil dog sige at *rigtigt* mange programmer kan med fordel programmeres i Java eller .NET da performance tabet er irrelevant.
#27
1) Det er jo flot at du har bøger. Jeg har også læst at solen er grøn i en bog. Måske du kunne henvise til hvilke bøger det er du læser.
2) Som det har været sagt, så er det jo ikke .Net's skyld, men udviklerne af VS. Brug notepad i stedet, eller #develop.
3) Så du mener at OR-mappers er noget fanden har opfundet på en dårlig dag? OR-mappers findes forresten også i mange andre sprog, så jeg forstår ikke hvorfor du skal kritisere .Net for det. Og hvis du gerne vil skrive SQL, then be my guest. IDbCommand og IDataReader er perfekte til det formål.
#37
Nej, .Net API'et er ikke en wrapper omkring MFC, men omkring Win32. Og hvorfor det skal få høvl for det kan jeg ikke forstå. Hvordan i alverden vil folk ellers have at det skal laves? Det kører for fanden på windows, og her er laveste fællesnævner Win32, så de ting der ikke kan implementeres direkte i .Net eller CLR'en må gå igennem Win32.
Som udvikler i .Net gennem 4 år må jeg sige at fungerer rigtig godt og synes at deres .Net API er meget intuitivt bygget op. Eneste sted jeg oplever slinger i valset er GDI+ som alt for ofte kommer med en Generic GDI Exception.
Det er dog ikke kun lyserøde skyer. Jeg har læst store dele af .Net Frameworkets sourcecode igennem, og her er det tydeligt at se at MS har måtte gå på kompromis for at få et så flot API som de har. Utrolig mange klasser og wrappere omkring Win32-kald er lavet internal og ser ikke altid lige pæne ud. Der er også mange klasser som man kunne ønske sig ikke var sealed, men hvis man kigger nærmere på dem er de internt et virvar, og så forstår man pludselig hvorfor man helst ikke skal prøve på at udvide dem.
Det er selvfølgelig ærgeligt, og man kan kun håbe at de for ryddet op i noget af det i .Net 2.0 eller i Longhorn. Men at sige at det eksisterende API som er tilgængeligt for programmøren er noget rod vil jeg gerne se nogle konkrete eksempler og links på.
1) Det er jo flot at du har bøger. Jeg har også læst at solen er grøn i en bog. Måske du kunne henvise til hvilke bøger det er du læser.
2) Som det har været sagt, så er det jo ikke .Net's skyld, men udviklerne af VS. Brug notepad i stedet, eller #develop.
3) Så du mener at OR-mappers er noget fanden har opfundet på en dårlig dag? OR-mappers findes forresten også i mange andre sprog, så jeg forstår ikke hvorfor du skal kritisere .Net for det. Og hvis du gerne vil skrive SQL, then be my guest. IDbCommand og IDataReader er perfekte til det formål.
#37
Nej, .Net API'et er ikke en wrapper omkring MFC, men omkring Win32. Og hvorfor det skal få høvl for det kan jeg ikke forstå. Hvordan i alverden vil folk ellers have at det skal laves? Det kører for fanden på windows, og her er laveste fællesnævner Win32, så de ting der ikke kan implementeres direkte i .Net eller CLR'en må gå igennem Win32.
Som udvikler i .Net gennem 4 år må jeg sige at fungerer rigtig godt og synes at deres .Net API er meget intuitivt bygget op. Eneste sted jeg oplever slinger i valset er GDI+ som alt for ofte kommer med en Generic GDI Exception.
Det er dog ikke kun lyserøde skyer. Jeg har læst store dele af .Net Frameworkets sourcecode igennem, og her er det tydeligt at se at MS har måtte gå på kompromis for at få et så flot API som de har. Utrolig mange klasser og wrappere omkring Win32-kald er lavet internal og ser ikke altid lige pæne ud. Der er også mange klasser som man kunne ønske sig ikke var sealed, men hvis man kigger nærmere på dem er de internt et virvar, og så forstår man pludselig hvorfor man helst ikke skal prøve på at udvide dem.
Det er selvfølgelig ærgeligt, og man kan kun håbe at de for ryddet op i noget af det i .Net 2.0 eller i Longhorn. Men at sige at det eksisterende API som er tilgængeligt for programmøren er noget rod vil jeg gerne se nogle konkrete eksempler og links på.
#40
.Net og sql2000 er ikke mere knyttet sammen, end den provider du bruger mellem dem, og sqlclient er bare en provider ms har stillet til rådighed, ligesom oracle har stillet deres egen tilrådighed - hvis du skulle bruge oracle.
sql2005 vil ændre på det, da .net 2.0 og sql2005 bliver knyttet sammen af mere end bare en provider, det vil i starten give udvikleren og applikationen fordele med hensyn til brugen af sql2005 ( cache dependency / .net i db osv... )
.Net og sql2000 er ikke mere knyttet sammen, end den provider du bruger mellem dem, og sqlclient er bare en provider ms har stillet til rådighed, ligesom oracle har stillet deres egen tilrådighed - hvis du skulle bruge oracle.
sql2005 vil ændre på det, da .net 2.0 og sql2005 bliver knyttet sammen af mere end bare en provider, det vil i starten give udvikleren og applikationen fordele med hensyn til brugen af sql2005 ( cache dependency / .net i db osv... )
#46 selvfølgelig rigtig nok. Men jeg tror ikke at MSSQL vil vinde frem specielt på grund af den ekstra optimering, da MySqlConnector også er pænt optimeret til MySQL, men mere på grund af at den er standard med i .Net Frameworket, og at artikler og tutorials på nettet har tendens til at skrive MSQSQL specifik kode fremfor at benytte interfaces. Det gælder også codesnippets fra MSDN som næsten alle er skrevet til MSSQL.
Det vil helt sikkert også have indflydelse.
Jeg sad selv og kodede mit første .net projekt for et par uger siden. Jeg skulle bruge en database og læste i min bog, at MSSQL providere var optimeret i forhold til performance, derfor valgte jeg en MSSQL database og derfor mit indlæg, da jeg antog at mange andre ville tænke som mig.
Jeg sad selv og kodede mit første .net projekt for et par uger siden. Jeg skulle bruge en database og læste i min bog, at MSSQL providere var optimeret i forhold til performance, derfor valgte jeg en MSSQL database og derfor mit indlæg, da jeg antog at mange andre ville tænke som mig.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund