J2EE vs ASP.NET benchmark results discussie

[Verwijderd]

Ik werk zelf met ASP.NET maar ben altijd erg benieuwd naar andere programmeertalen en platformen. Ik ben een tijdje geleden opzoek gegaan naar vergelijkingen tussen .NET en J2EE. Ik heb toen de volgende benchmark gevonden:

http://www.middleware-com...s/j2eedotnetbenchmark.pdf

Middleware heeft de twee voorbeeld applicaties, die best-practises aangeven, van beide platformen geoptimatiseerd en vergeleken (de PET store. Is een webwinkel ontwikkeld in beide omgevingen.)

Uit de test komt een duidelijke winnaar. Het lijkt mij dus duidelijk welke de winnaar is.

Maar vaak zijn er expert die trucjes oid aan het licht brengen die een verschuiving in de benchmarks zouden kunnen veroorzaken.

Daarom wou ik weten of er iets ontbreekt in deze vergelijkingen.

Ik hoop niet dat er een ASP.NET vs J2EE discussie komt want die zijn zinloos. Maar wel hoe de results van deze benchmark geinterperteerd moeten worden. Daarom aub ook alleen reageren als je gehele benchmark hebt doorgenomen.

[whoami]

Hmmm.... Ik geloof dat dit hier al eens gepost werd.
Is dat niet die benchmark die door MS gesponsort werd oid?

[Verwijderd]

whoami schreef op 10 December 2002 @ 15:59:
Hmmm.... Ik geloof dat dit hier al eens gepost werd.
Is dat niet die benchmark die door MS gesponsort werd oid?

Er is hierover een discussie geweest in Area61, die is niet publiekelijk toegankelijk helaas...

edit:
Hier: .net vs Java, wat voor conclusies uit dit artikel?

[ Voor 12% gewijzigd door Verwijderd op 10-12-2002 16:07 ]

[Verwijderd]

Nee lees AUB eerst de results... niks gesponseerd.... middleware die de benchmarks gedaan heeft is gespecialiseerd in J2EE, en die komt niet als...... nou bekijk die results maar...

[JeroenB]

Om te beginnen denk ik dat dit soort vergelijkingen in de praktijk alleen maar uit zullen draaien op flamewars. Anderzijds twijfel ik aan de resultaten aangezien een groot deel van deze benchmark te maken heeft met software ontwikkeling, die op het gebied van performance nogal afhankelijk is van de ontwikkelaar.

Als ik de resultaten bekijk ziet het er overigens naar uit dat ze allebei goed schalen, alleen dat .NET (volgens deze benchmarks) beter performed. Of dat wel of niet zo is in real-world situaties hangt van veel meer dingen af dan je met een online dierenwinkel kunt aantonen.

Je zou IMHO hoogstens kunnen stellen dat Microsoft's ervaring met eerdere incarnaties van Enterprise applicaties (oa. hun Windows DNA) ervoor heeft gezorgd dat ze zonder achterstand in de arena terecht zijn gekomen. Iets dat me niet zou verbazen en dus wel plausibel is.

[Glimi]

Volgens mij wordt hier harder MS SQL Server vs. Oracle getest, samen met de drivers die hiervoor bij het door hun 'geteste' platform gebruikt is.

[Verwijderd]

Ja wil alles behalve flamewar.. Maar ik denk niet dat de benchmarks afhankelijk zijn van de ontwikkelaar. Deze test is tijden geleden door Microsoft gedaan en toen was de J2EE versie niet geoptimaliseerd voor snelheid. Er is nu naar Microsft en Sun geluisterd en naar ontwikkelcommunities. Maar dit staat allemaal in het document. Ben eigenlijk opzoek naar factoren die niet in het document staan maar wel van belang zijn.

[JeroenB]

Dat zei ik dus, ontwikkelaar a die naar Microsoft luistert en de bijbehorende communities produceert toch andere code dan ontwikkelaar b die hetzelfde doet. En reken maar dat dat impact heeft op performance.

[Verwijderd]

JeroenB schreef op 10 December 2002 @ 16:16:
Dat zei ik dus, ontwikkelaar a die naar Microsoft luistert en de bijbehorende communities produceert toch andere code dan ontwikkelaar b die hetzelfde doet. En reken maar dat dat impact heeft op performance.

Sorry, niet helemaal 100% duidelijk. Community's hebben na de 1e benchmark van Microsoft gezegd ja maar de .NET versie is geoptimaliseerd voor snelheid. Toen zei middleware ok, dan doen wij een onafhankelijke test met beide platformen geoptimaliseerd voor snelheid. Sun en Microsoft hebben dus tips en instructies gegeven van zo kan onze techniek het beste gebruikt worden om de hoogste snelheid -> benchmark results te halen. Factor ontwikkelaar is hier dus GEEN item.

[JeroenB]

Persoonlijk denk ik dat er wel mensen zijn die Microsoft spullen sneller krijgen dan MS zelf, hetzelfde geldt voor Sun. De ontwikkelaar is dus *altijd* een factor, tenzij je ze allemaal een implementatie laat doen (alle ontwikkelaars op aarde) en dan de snelsten met elkaar vergelijkt.

Zelfs dan kun je nog discussieren of er niet meer ontwikkelaars voor platform x bestaan en die dus waarschijnlijk de beteren heeft etc.

[Unipuma]

Kijk even op:
http://www.middleware-company.com/j2eedotnetbench/faq.shtml
Hierin geeft de Middleware-company zelf aan met welke 'kanttekeningen' de benchmark gelezen moet worden. Hierin wordt eigenlijk heel duidelijk aangegeven dat het niet als een perfomance benchmark moet worden gezien tussen dotNet en Java, en eigenlijk lijkt het er ook op dat men toch wel enigszins spijt heeft van het wat haastig gepubliceerde artikel.
Niet voor niets is er veel commentaar geweest op dit artikel, en ik zou het dus ook niet gebruiken als argument om voor dotNet dan wel Java te kiezen.

Het dichts bij objectieve benchmarks dat je kunt komen is momenteel via TPC, maar ook hier geld dat resultaten pas worden ingestuurd door bedrijven nadat hun hele omgeving is gefine-tuned, en men alleen positieve resultaten zal publiceren.

Waarschijnlijk zal de conclusie moeten zijn dat voor elke situatie en andere configuratie eigenlijk een eigen benchmark nodig is.

[Verwijderd]

je hebt lies, damn lies en benchmarks. Het uitzetten van arraybound checks bv levert in .NET en Java veel voordeel op. Is dat in .NET wel en in java niet uitgezet? geen idee. Een foreach loop die een ArrayList uitleest is vele malen trager dan een for loop die via de indexer de arraylist benadert. Zo kun je met simpele taalconstructies toch veel voordelen halen uit je implementatie terwijl die niet echt zichtbaar zijn, tenzij je echt gaat profilen en daarna de trage stukken code gaat doorlichten.

De JVM draaiend op Solaris zou in theorie even snel moeten zijn als de CLR draaiend op win2k server. Ik zou deze en andere benchmarks gewoon terzijde schuiven, want die paar procent winst is nl. niet belangrijk.

Waar ik me echt MA TE LOOS aan geergerd heb is het gezeik van menige java/linux troll over dat dit onderzoek gefinancierd is door Microsoft. Ja, en? Ten eerste kosten dit soort onderzoeken veel geld, dus doen dit soort instituten dat niet op eigen initiatief. Ten tweede impliceert de opmerking dat het door microsoft gefinancierd is dat het onderzoek niet rechtvaardig is (lees: corrupt). De sources van beide applicaties zijn te downloaden. Ik heb nog niet een artikel gelezen waaruit bleek dat de Java implementatie dermate triest in elkaar zat dat het een scheef onderzoek was.

De vorige keer dat de petshop werd gebruikt, de 1e keer door MS zelf, won .NET met 3 vingers in elk neusgat. Dit was niet verwonderlijk, de petshop is bv net als IBuySpy voor .NET een voorbeeld app en niet gebouwd voor snelheid. Oracle heeft hem toen omgeschreven en toen was de petshop implementatie beduidend sneller.

[Verwijderd]

Unipuma schreef op 10 December 2002 @ 16:36:
Kijk even op:
http://www.middleware-company.com/j2eedotnetbench/faq.shtml
Hierin geeft de Middleware-company zelf aan met welke 'kanttekeningen' de benchmark gelezen moet worden. Hierin wordt eigenlijk heel duidelijk aangegeven dat het niet als een perfomance benchmark moet worden gezien tussen dotNet en Java, en eigenlijk lijkt het er ook op dat men toch wel enigszins spijt heeft van het wat haastig gepubliceerde artikel.
Niet voor niets is er veel commentaar geweest op dit artikel, en ik zou het dus ook niet gebruiken als argument om voor dotNet dan wel Java te kiezen.

Geef me _EEN_ link naar een onderbouwd stukje commentaar op deze test waaruit blijkt dat de test flawed is en dat je er geen conclusies uit mag trekken. EEN!. Dat kun je niet, want die zijn er niet.

Ik herinner me mindcraft. Ze toonden aan dat Linux zoog tov NT. Oh, wat kreeg Mindcraft een stortvloed aan shit over zich heen. Microsoft had deels het onderzoek betaalt en DUS was het corruptie ten top! Echter, onafhankelijke tests die exact volgens de Mindcraft methode werden uitgevoerd bleken dezelfde resultaten op te leveren. Flawed? Nee, in het geheel niet. Zelfs Linus heeft hier later over toegegeven fout te zitten. De test heeft wel aangezet tot een effientere kernel dus ik denk dat de trolls van welleer Mindcraft er beter om kunnen danken dan haten.

ALs een java programma trager is dan een C# programma, dan is dat puur door:
- tragere JIT
- slechtere calling van de JIT/JVM van OS-specifieke platformlibfuncties.

Het zegt dus niets over de taal, maar over de implementatie van de JVM.

Het dichts bij objectieve benchmarks dat je kunt komen is momenteel via TPC, maar ook hier geld dat resultaten pas worden ingestuurd door bedrijven nadat hun hele omgeving is gefine-tuned, en men alleen positieve resultaten zal publiceren.

De TPC is iets heel anders. En ook daar zijn de meningen over verdeeld. Aangezien Oracle en Sun al jarenlang geen topplaats meer voor elkaar krijgen in menige TPC lijst, gaat het gemor toch wat groteske vormen aannemen, de TPC zou niet realistisch zijn etc.

[mbravenboer]

Benchmarks zijn zeer lastig zuiver te houden. Ik geloof zelf eigenlijk alleen maar in micro benchmarks die proberen om het aantal factoren zoveel mogelijk te beperken en alleen 1 klein facet te testen.

Als er dus al een benchmark uitgevoerd moet worden zie ik graag een groot aantal micro benchmarks waar je dan zelf een oordeel aan kan verbinden.

Toevallig zag ik gisteren nog een benchmark die het aanroepen van virtuele methoden test. Java kwam er hier voor de afwisseling eens goed vanaf omdat er at runtime geoptimaliseerd kan worden. Bij .NET is dit een stuk lastiger omdat alle IL volledig gecompileerd wordt voordat het wordt uitgevoerd. Dit zorgt ervoor dat de server-side Hotspot alle virtuele calls kan optimaliseren. Het gevolg hiervan is wel dat de responsiviteit van een applicatie tijdelijk afneemt. Vandaar dat de client-side Hotspot compiler dit niet doet. .NET Framework maakt voor zover ik weet ook geen onderscheid tussen server-side en client-side JIT compilatie, waardoor Java er in bepaalde situaties altijd positief uit zal komen: het kost immers ook wat.

[Verwijderd]

Unipuma schreef op 10 December 2002 @ 16:36:
Het dichts bij objectieve benchmarks dat je kunt komen is momenteel via TPC, maar ook hier geld dat resultaten pas worden ingestuurd door bedrijven nadat hun hele omgeving is gefine-tuned, en men alleen positieve resultaten zal publiceren.

In het document staat ook een gedeelte over Kosten Per Transactie. Is dit geen goede maatstaaf?

[Verwijderd]

Normaalgesproken reageer ik nooit op J2EE v. .Net discussies maar voor deze benchmark maak ik graag een uitzondering.

Aangezien hier mensen onderbouwde kritiek willen hebben over deze test zou ik ze aanraden de volgende links door te lezen.

http://dreambean.com/petstore.html

en een link van een .Net site zelf
http://www.dotnetguru.org...e/PetShopArchitecture.htm

English translation of this paper:
http://www.ejbsig.de/docs/PetShopArchitecture.html

Ik wordt een beetje moe van alle .Net is beter, J2EE is beter, etc.. etc..

Kijk wat in jouw situatie het beste is, maar baseer die keuze niet op een aantal benchmarks. Baseer het op de zaken die voor jou belangrijk zijn. Integratie in huidige architectuur, tools, maintainability etc.

Just my 2 cents...

[Verwijderd]

Verwijderd schreef op 10 december 2002 @ 19:11:
Normaalgesproken reageer ik nooit op J2EE v. .Net discussies maar voor deze benchmark maak ik graag een uitzondering.

Ja die discussie zijn ook nutteloos... heb daarom ook niet topic, maar wil weten of als je deze benchmark bijvoorbeeld gebruikt om een keuze te maken tussen beide platformen in hoeverre je deze benchmark kan gebruiken en vooral, wat ontbreekt eraan (niet in vergelijking maar in benchmark). Zie het dan ook liever als Product X vs Product Y maar ja klinkt ook zo raar. Product is hier niet van belang... benchmark wel. Maar heb het idee, aan de reacties te zien, dat het ook zo benaarderd wordt.

[Verwijderd]

Misschien trouwens wel leuk om een op basis van de GOT database twee applicaties te maken, 1 in J2EE en 1 in .NET en dan eigen benchmarks maken. Maar ja wie heeft er de tijd voor... misschien kom ik daar nog wel eens op terug.

[Scare360]

Ik zie dergelijke benchmarks als 100% bullshit, maar begrijp dat het nuttig_is om de haantjes bezig te houden. Techniek moet je gebruiken. Schiet de eindgebruiker er iets mee op indien ik...

Verder 9/10 krijg je blah v.s. bluh.

Verder ben ik zowel over .NET als Java te spreken, maar verkies .NET vanwegen de support, IDE, documentatie etc boven Java (ben verziekt met Visual Cafe).

[JeroenB]

paulgielens schreef op 10 december 2002 @ 23:23:Verder ben ik zowel over .NET als Java te spreken, maar verkies .NET vanwegen de support, IDE, documentatie etc boven Java (ben verziekt met Visual Cafe).

Dat is wel een interessant punt, aangezien het voor mij ook zo is en ik al langer denk dat zoiets toch een belangrijke factor moet gaan worden. Ik heb jaren in Java zitten programmeren maar heb nooit een IDE gevonden die zo lekker werkt als Devstudio van MS, hetzelfde geldt voor documentatie bij MS in de vorm van MSDN die elke paar maanden op de mat ploft. Gevolg is dat ik nu zelf met .NET bezig ben.

Uiteindelijk zou de performance dus lang niet alles zijn. Klopt ook wel als je kijkt naar die benchmarks: OK .NET komt er daar een stuk sneller uit, maar de resultaten van Java in combinatie met de gebruikte hardware en typische toepassing die dat zou meebrengen zijn ook gewoon goed te doen. Allebei schalen ze ook netjes (verhoudingsgewijs gaat de performance bij beiden mooi en met ruwweg dezelfde curve omhoog bij het inzetten van extra hardware) en daar gaat het toch om: Of je voor oplossing 1 een stuk of 5 bakken nodig hebt en voor oplossing 2 het dubbele, verhoudingsgewijs duwt het allebei niet zo zwaar op de begroting van een project dat groot genoeg is voor zo'n omgeving.

Pas als je bij applicaties als Google terechtkomt wordt het cruciaal dat het onderste uit de kan wordt gehaald, maar hoe groot en prestigieus die projecten ook zijn, het grote geld zit toch in de 99% onder het topsegment, van het MKB tot aan de onderkant van de Fortune500.

[ Voor 10% gewijzigd door JeroenB op 10-12-2002 23:30 . Reden: Laatste alinea toegevoegd ]

[Glimi]

JeroenB schreef op 10 December 2002 @ 23:28:
Dat is wel een interessant punt, aangezien het voor mij ook zo is en ik al langer denk dat zoiets toch een belangrijke factor moet gaan worden. Ik heb jaren in Java zitten programmeren maar heb nooit een IDE gevonden die zo lekker werkt als Devstudio van MS, (..)

[edit] IntelliJ Idea moet je heel even proberen dan, wordt door veel mensen geroemd om zijn kwaliteiten als IDE

[JeroenB]

Glimi schreef op 11 December 2002 @ 07:40:IntelliJ Idea moet je heel even proberen dan, wordt door veel mensen geroemd om zijn kwaliteiten als IDE

Ik heb de vorige versie (2.6) daarvan nog gebruikt en zou het ook aanbevelen aan mensen die Java programmeren, daarentegen vond ik de geintegreerde help-mogelijkheden niet zo goed als bij VS met MSDN, maar dat is niet echt de schuld van IntelliJ maar komt meer door de minder handige docs die Sun zelf levert.

Daarnaast zijn de makkelijke integratiemogelijkheden met unmanaged code ook wel een belangrijk (technisch) pluspunt voor mij. Bij Java is dat toch allemaal wat lastiger (alhoewel ik de nieuwste JDK niet meer gebruikt heb, ik ben er mee gestopt )

[Verwijderd]

Bij ons werken ze voornamelijk met JBuilder 6. Wat op zich wel een aardige IDE is maar weinig mogelijkheden biedt voor refactoring and sourcegeneration.

Ikzelf ben pas compleet overgestapt op Eclipse. Eclipse is even wennen maar heeft erg goede CVS integratie, veel refactoring mogelijkheden en is gratis.

Niet om in een discussie te vervallen over opensource wel/niet toch even een kleine opmerking over iets wat hierboven gepost is.

Er wordt gesproken over cost per transaction als maatstaaf. Heel de j2ee petshop kan makkelijk met opensource/gratis te verkrijgen software ontwikkeld worden met redelijke performance.

Als je dat dan als maatstaaf wil gebruiken komt j2ee er wel heel goed uit

[JeroenB]

Verwijderd schreef op 11 december 2002 @ 09:21:Er wordt gesproken over cost per transaction als maatstaaf. Heel de j2ee petshop kan makkelijk met opensource/gratis te verkrijgen software ontwikkeld worden met redelijke performance.

Als je dat dan als maatstaaf wil gebruiken komt j2ee er wel heel goed uit

Volgens mij vallen die Windows Server licenties in prijs ook wel mee. Het .NET Framework compleet met compilers e.d. zijn ook gratis te downloaden bij Microsoft. Je kunt waarschijnlijk ook een gratis versie van MSDE gebruiken als database, maar mocht dat licentietechnisch toch niet kunnen dan kan je vast wel een verbinding maken met een gratis/opensource database - dat moet bij die gratis J2EE oplossing toch ook.

[Bobco]

JeroenB schreef op 11 December 2002 @ 09:50:
[...]

Volgens mij vallen die Windows Server licenties in prijs ook wel mee. Het .NET Framework compleet met compilers e.d. zijn ook gratis te downloaden bij Microsoft. Je kunt waarschijnlijk ook een gratis versie van MSDE gebruiken als database, maar mocht dat licentietechnisch toch niet kunnen dan kan je vast wel een verbinding maken met een gratis/opensource database - dat moet bij die gratis J2EE oplossing toch ook.

Je hebt gelijk met je opmerking dat de licentie-kosten in prijs wel meevallen. Maar zoals hierboven ook al is opgemerkt is deze benchmark een optelsom van heel veel factoren. De performance van de onderliggende database speelt ook een rol. Op het moment dat je MS SQL Server gaat vervangen door iets anders (en MSDE mag je geloof ik voor maximaal 5 concurrent users inzetten) dan kan de vergelijking weer heel anders uitvallen.

Dit geeft ook meteen aan hoe moeizaam het discussieren over dit onderwerp is. Er zijn veel te veel onbekende variabelen in het verhaal om een echt zinnige vergelijking te kunnen maken.

[Verwijderd]

De .NET implementatie gebruikte geen Stored procedures. Bij het gebruik daarvan zal de performance gemiddeld nog meer toenemen. Het gebruik van MSDE kan limiteren werken, maar tot 30 gebruikers heb je daar niet zoveel last van (hangt een beetje van je code af natuurlijk). MSDE executeert max 5 T-SQL statements per tick, dus je kunt meer dan 5 users bedienen zonder timeouts.

Wat de onderzoekers gelijk hebben gehouden is de hardware en het OS en dat is voor Java denk ik de grootste nekslag geweest. Was Solaris geinstalleerd dan was de performance van Java hoger geweest.

[Alarmnummer]

Wat ik uit een artikeltje op javalobby heb begrepen (dus je mag je dan ook afvragen hoe objectief het is), is dat MS het petshop design goed naar zijn grootje heeft geholpen in ruil voor performance. Aan de java kant is dit niet gebeurd, dus daarom is het ook een oneerlijke vergelijking.

Verder vind ik de vergelijking sowieso een beetje vragen om problemen. De vm`s en de compilers worden toch wel beter, maar dat doet verder niets af aan de taal of de omgeving. Als de snelheid acceptabel is, dan zou ik eerdere op andere zaken gaan letten dan performance.

[edit]
Ik ben vergeten erbij te vermelden welk design, namelijk Petshop.

[ Voor 9% gewijzigd door Alarmnummer op 11-12-2002 11:40 ]

[whoami]

Nouja, als je dat mag geloven, dan is het maar een kwestie waar je meer prioriteit aangeeft: design v/h framework of performance.

* whoami vind het design van het .NET framework anders wel aardig.

[Alarmnummer]

JeroenB schreef op 11 december 2002 @ 09:50:
Je kunt waarschijnlijk ook een gratis versie van MSDE gebruiken als database, maar mocht dat licentietechnisch toch niet kunnen dan kan je vast wel een verbinding maken met een gratis/opensource database - dat moet bij die gratis J2EE oplossing toch ook.

Ik weet niet in hoeverre het mogelijk is om iets anders dan SQL Server in te schakelen in VS op de manier zoals dat met SQL Server ook gaat. Als je nog steeds even eenvoudig ermee kan werken dan is het natuurlijk geen probleem, maar als de IDE een stuk moeizamer omgaat dat gaat het voor ontwikkelaars natuurlijk weer iets minder aantrekkelijk worden (oa omdat ze meer tijd kwijt zijn) om een andere database te gebruiken.

[JeroenB]

Bobco schreef op 11 december 2002 @ 11:07:
Je hebt gelijk met je opmerking dat de licentie-kosten in prijs wel meevallen. Maar zoals hierboven ook al is opgemerkt is deze benchmark een optelsom van heel veel factoren. De performance van de onderliggende database speelt ook een rol. Op het moment dat je MS SQL Server gaat vervangen door iets anders (en MSDE mag je geloof ik voor maximaal 5 concurrent users inzetten) dan kan de vergelijking weer heel anders uitvallen.

Het ging hier dan ook om een prijsvergelijking en niet eentje rondom performance Gemiddeld zal de performance van de J2EE-oplossing namelijk ook anders worden omdat een gratis versie daarvan ook niet op Oracle kan draaien.

[ Voor 1% gewijzigd door JeroenB op 11-12-2002 11:40 . Reden: formatting ]

[whoami]

Alarmnummer schreef op 11 december 2002 @ 11:39:
[...]

Ik weet niet in hoeverre het mogelijk is om iets anders dan SQL Server in te schakelen in VS op de manier zoals dat met SQL Server ook gaat. Als je nog steeds even eenvoudig ermee kan werken dan is het natuurlijk geen probleem, maar als de IDE een stuk moeizamer omgaat dat gaat het voor ontwikkelaars natuurlijk weer iets minder aantrekkelijk worden (oa omdat ze meer tijd kwijt zijn) om een andere database te gebruiken.

MS heeft voorlopig 2 namespaces in het .NET framework zitten met daarin classes om databank-toegant etc te verkrijgen:

code:

System.Data.OleDb
System.Data.SqlClient

De classes in beide namespaces zijn qua naamgeving vrijwel hetzelfde (OleDbConnection vs SqlConnection) en ze implementeren ook beiden dezelfde interfaces. Het is dus enkel een kwestie van het type te veranderen, en je bent er.

Je kunt natuurlijk een abstract factory pattern opzetten en uit een config file gaan uitlezen welk type databank je wilt accessen (Sql Server of iets anders) en dan kan die abstract factory natuurlijk de juiste classes voor jou gaan gebruiken.

Of bedoelde je iets over de 'Server Explorer' in VS.NET?

[ Voor 3% gewijzigd door whoami op 11-12-2002 11:44 ]

[Alarmnummer]

Ik bedoel meer de binding met VS zelf. Gewoonlijk heb je in een paar tellen een database in elkaar gezet, een datababinding framework gegenereerd en je bent al bijna klaar. Maar hoe gaat dit bij een Database anders dan SQL Server. En hetzelfde geld voor IIS. In hoeverre is het mogelijk om een andere WebServer erin te zetten.

Volgens mij zit je als je voor de vs manier van werken gaat toch al vrij snel vast aan ms producten. Omdat ze te makkelijk te gebruiken zijn en uitstekend zijn geintegreerd in de IDE.

[ Voor 87% gewijzigd door Alarmnummer op 11-12-2002 11:47 ]

[whoami]

Daar heb ik totnutoe nog geen ervaring mee.
* whoami gebruikt op dit moment VS.NET, SQL Server en IIS.

Ik kan me wel voorstellen dat, als je een .NET applicatie in elkaar zet en daarbij gebruik wilt maken van een Oracle DB, dat Oracle ook wel de nodige (CASE)tools heeft (Oracle Designer) om een databank te gaan genereren. Als die dan niet integreerbaar is in VS.NET, tja, too bad, maar ik zal er niet wakker van liggen.

[Verwijderd]

Alarmnummer schreef op 11 December 2002 @ 11:39:
[...]

Ik weet niet in hoeverre het mogelijk is om iets anders dan SQL Server in te schakelen in VS op de manier zoals dat met SQL Server ook gaat. Als je nog steeds even eenvoudig ermee kan werken dan is het natuurlijk geen probleem, maar als de IDE een stuk moeizamer omgaat dat gaat het voor ontwikkelaars natuurlijk weer iets minder aantrekkelijk worden (oa omdat ze meer tijd kwijt zijn) om een andere database te gebruiken.

Geen enkele stored procedure programmeur gebruikt VS.NET om stored procedures te maken in sqlserver, dat ding werkt nl. niet (je maakt een stored procedure met ergens een typo, je wilt dat ding runnen (dus dat hij de create procedure aanroept) maar dat werkt niet ivm die typo, je krijgt alleen "Error, can't continue" te zien. Niet welke error, niet waar .. Dus dat is al uitgesloten.

Verder heeft zowel Oracle als MS een Oracle native provider geleverd voor oracle databases in .NET. Dus native communicatie via de ADO.NET spullen met oracle. Dus qua performance zit dat wel snor. Binnen de IDE heb je daar totaal geen problemen mee (ook niet met bv de mysql native provider) want ze implementeren allemaal dezelfde interfaces en die worden bv gebruikt voor intellisense)

[Bobco]

whoami schreef op 11 December 2002 @ 11:38:
Nouja, als je dat mag geloven, dan is het maar een kwestie waar je meer prioriteit aangeeft: design v/h framework of performance.

* whoami vind het design van het .NET framework anders wel aardig.

Het ging niet om het design van .Net of J2EE maar om de design patterns die gebruikt zijn bij de implementatie die oorspronkelijk van de PetShop is gemaakt door Sun. Die was gedeeltelijk bedoeld (IIRC) als demonstratie van een ontwerp dat oa gemakkelijk onderheoudbaar moest zijn. Performance was niet het hoogste doel.

De MS implementatie van de PetShop werd er door mensen uit de Java-community van verdacht dat het puur op performance was geschreven en dat de design patterns die door Sun waren gebruikt 'om zeep waren geholpen.'

Maar goed, ik ga hier steeds meer dingen zeggen die ik van horen zeggen heb en dat maakt de discussie hier er ook niet duidelijker op.

Overigens vind ik dat de enige zinnige vergelijking voor een bedrijf de vergelijking van de totale kosten van een applicatie, gedurende de hele levensduur. Dan kom je helaas weer terecht in de bekende discussies over TCO en wat je wel en niet mag meerekenen en wat daar dan weer wel en niet belangrijk van is.

Keuzes worden vaak gebaseerd op keuzes die in het verleden gemaakt zijn en een organisatie die z'n hele back offdice op Unix oid heeft draaien zie ik niet 123 .Net gebruiken. Andersom geldt dat net zo goed.

[whoami]

Verwijderd schreef op 11 december 2002 @ 12:01:
[...]

Geen enkele stored procedure programmeur gebruikt VS.NET om stored procedures te maken in sqlserver, dat ding werkt nl. niet (je maakt een stored procedure met ergens een typo, je wilt dat ding runnen (dus dat hij de create procedure aanroept) maar dat werkt niet ivm die typo, je krijgt alleen "Error, can't continue" te zien. Niet welke error, niet waar .. Dus dat is al uitgesloten.

SP's maken doe ik ook niet in VS.NET, daar gebruik ik de Query Analyzer voor.

Verder heeft zowel Oracle als MS een Oracle native provider geleverd voor oracle databases in .NET. Dus native communicatie via de ADO.NET spullen met oracle. Dus qua performance zit dat wel snor. Binnen de IDE heb je daar totaal geen problemen mee (ook niet met bv de mysql native provider) want ze implementeren allemaal dezelfde interfaces en die worden bv gebruikt voor intellisense)

Nou, het voordeel van die interfaces is niet alleen 'Intellisense'. Je weet dat je ieder object die die interface implementeert op een eenvormige manier kunt aanspreken, en je kunt het dan ook gebruiken om, zoals ik reeds zei dmv een Abstract Factory de juiste classes te laten creeëren.

[Verwijderd]

Bobco schreef op 11 December 2002 @ 12:04:
[...]


..
De MS implementatie van de PetShop werd er door mensen uit de Java-community van verdacht dat het puur op performance was geschreven en dat de design patterns die door Sun waren gebruikt 'om zeep waren geholpen.'

Maar goed, ik ga hier steeds meer dingen zeggen die ik van horen zeggen heb en dat maakt de discussie hier er ook niet duidelijker op.

Niet alleen door mensen uit de Java-community wordt kritiek geleverd, lang niet iedereen uit de .Net community is zo blij met deze benchmarks.

Zoals ik al eerder linkte kijk eens op de volgende site:
http://www.dotnetguru.org...e/PetShopArchitecture.htm (in het Frans)
http://www.ejbsig.de/docs/PetShopArchitecture.html (of in het Engels)

Daar wordt stap voor stap de source van de .Net implementatie besproken en toegelicht welke Anti-patterns er allemaal gebruikt worden (layers overslaan etc.)

[Bobco]

Verwijderd schreef op 11 December 2002 @ 13:17:
[...]
http://www.ejbsig.de/docs/PetShopArchitecture.html (of in het Engels)

Daar wordt stap voor stap de source van de .Net implementatie besproken en toegelicht welke Anti-patterns er allemaal gebruikt worden (layers overslaan etc.)

Bijzonder interessante link, dank je wel. Je kunt je afvragen wat het _onderhouden_ van een applicatie kost die zo is opgezet.