______________________________________________________________ > Od: [EMAIL PROTECTED] > Komu: Java <[email protected]> > Datum: 31.10.2006 10:53 > Předmět: Re: Co jde v .NET a nejde v Jave? > >On Tuesday 31 October 2006 10:13, Radovana Straube wrote: >> Dobry den, >> >> C#.NET je vyzrelejsi jazyk, pretoze bol zostaveny >> neskor, na principoch Javy, a vyvaroval sa jej chyb a >> nedostatkov. Napr. anotacie tam existovali uz davno. >> Vsetky funkcie su pekne dokumentovane, Microsoft >> proste staval na svojich skusenostiach a rozsiroval >> iba bazu, ktoru uz mal. V .NET mozete pouzivat viacero >> jazykov, napr. Visual Basic, J# a pod.
Co se tyce dokumentace, tak v .NET podle mne neni dokumentace zas o moc lepsi nez v Jave (kdyz se budeme bavit zejmena o core J2SE knihovnach). Snad jen je v MSDN o neco vic prikladu jak konkretni tridu pouzit, ale myslim ze ani Java 1.5 uz se nema za co stydet (oproti napr. 1.3. verzi). V .NETu mi ale dost chybi moznost si prohlednout zdrojaky knihoven frameworku. Takze opravdu nezbyva nic jineho nez se spolehnout pouze na dokumentaci (coz nebyva idealni) nebo na google (to ale zbytecne zdrzuje). V Jave lze primo nahlednout do zdrojaku (napr. podivat se co vlastne vraci ten zatraceny Boolean.getBoolean(...) ze? :-). Co se tyce core knihoven, tak ty mi prijdou .NET knihovny ponekud vic intuitivni. Napr. string.IsNullOrEmpty() je docela uzitecna staticka metoda tridy String. V Jave musime psat porad dokola "if (s ==null || s.length() = 0)" (i o dost podivnejsi ekvivalenty lze casto potkat) nebo si napsat vlastni externi utilitu (prip. stahnout neco hotoveho z Jakarta Commons). Dale napr. prace s datumem (DateTime) a casovym usekem (TimeSpan) a jakym zpusobem se tyto 2 tridy dokonale doplnuji (scitani, odcitani, staticke helper metody na vytvareni) je ukazka jak ma .NET dobre propracovane nektere knihovny. Kdyz se pak clovek podiva na java.util.Date a ty mraky deprecated constructoru a metod, tak si uvedomi, ze vlastne cely Date je uz dnes jen docela osklivy wrapper nad jednou long promennou a nic vic... Ale neni to rozhodne to co by clovek intuitivne od Date tridy cekal. Pokud chci napriklad vytisknout cas tedy v .NETu "Console.WriteLine(DateTime.Now);" tak v Jave (jsem pres google http://www.rgagnon.com/javadetails/java-0106.html) zjistil ze musim pouzit minimalne tridy Calendar a SimpleDateFormat a provadet s tim docela slusne harakiri. Bez googlu, je toto prace na min. 5 minut. Dale nechapu proc napr. jinak velmi dobre propracovane java collections nemaji svuj vlastni package a motaji se do java.util kde se dneska nachazi uz kde co. Atd. ale to nema cenu dal rozebirat. Pokud se tyce podpory vice jazyku v .NETu, tak to mi prijde jako snad ta nejmensi vyhoda nebo argument. Nevim, ale asi malokdo v .NETu dneska pise v C++ nebo v J#. Udajne se v USA pise hlavne ve VB.NET a ve zbytku sveta vetsinou v C#. Jak uz Tapik psal, pro Javu VM existuje taky spousta jazyku, ale drtiva vetsina lidi je IMHO nikdy nebude mit potrebu pouzivat (aspon v nejblizsi dobe ne). >> Vyhoda Javy je aj v bezproblemovom nasadeni na Linuxe. >> Viem, ze uz bol napisany aj "VM" pre .NET pod Linuxom, >> ale o nejakom sirsom nasadeni som este nepocula. Ked >> sa clovek rozhodne pre .NET, takze sa v podstate >> rozhodol pre Windows. Mono nepodporuje vse co .NET od MS (napr. udajne GUI WinForms nic moc). Takze o dokonale prenositelnosti z windows na Unix (jako u Javy) nemuze byt asi rec. Mono vzniklo tusim tak, ze MS kdysi castecne naimplementoval verzi .NETu 1.0 na FreeBSD a dal od toho brzo ruce pryc (spis to byl marketingovy tah nez vazny umysl podporovat UNIX). A od te doby uz Mono s .NETem (1.1, 2.0, 3.0) IMHO nestaci prilis drzet krok (ale mozna se mylim). >> Myslim, ze zalezi aj na type programatora. Cloveku, >> ktory ma rad veci jasne nalinkovane, by viac vyhovoval >> .NET, lebo tam mate standardne kniznice a standardne >> postupy. Ak ste viac experimentatorsky typ a bavi vas >> hladat rozne projekty po Internete, tak by Vam asi >> viac vyhovala Java. Ale to je samozrejme len moj >> subjektivny nazor. To je pravda. V .NETu lze vetsinu veci delat jedinym zpusobem a ale vetsinou i snaze s mensim poctem vrstev, ktere je nutno rucne psat. Napr. GUI nebo Web prvky pracuji primo s datovmi objekty (ADO.NET), takze vetsinou odpada rucni plneni "Model" objektu z Entit, tedy vice mene odpada rucni prehazovani kupy dat tam a zase zpet (i kdyz napr. Jakarta BeanUtils lecos v tomhle smeru v Jave take zjednodusuji, ale v .NETu tohle funguje implicitne a automaticky). V Jave je urcite mnohem vetsi volnost vyberu knihoven to je fakt. Ale take je tim padem treba vybirat z ruznych variant, ktere se nabizi a to take stoji nejake usili. Napr. jaky persistentni framework (jen JDBC, Hibernate, JDO, Entity EJB...), jake MVC: (Struts, JSF, Tapestry nebo snad dokonce WebWork,...). Jestli vubec pouzit EJB container. Ale hlavne je pak treba doresit jak tyto (vetsinou nezavisle) frameworky navzajem zintegrovat v ramci jedne aplikace a mezi kolika dalsimi vrstvami budu presypavat data a vyjimky tam a zpet. Podobne je nutno v Jave resit i vyber aplikacniho serveru a databaze. V .NET je celkem jasno. Windows/IIS a hotovo. Databaze samozrejme MS SQL (kdyz 2005ka podporuje nativne nektere .NET typy a integrace do studia je bezproblemova). >Ve sve podstate je to tak. Chcete-li plne vyuzit .NET, MUSITE mit Visual >Studio, MSSQL, MS Windows, IIS, ... To je fakt. Bez toho to v podstate nejde. Neco snad dela Borland s Delphi a C# .NET IDE nebo jak se to jmenuje, ale jina volba pak uz asi neni. Tedy naprosta zavislost na MS a jejich cenach (zejmena jejich Serveru 2003, ktery uplne levny neni, zvlast v porovnani s Linuxem :-). petr >-- >Oto 'tapik' Buchta, [EMAIL PROTECTED] >http://www.buchtovi.cz > >______________________________________________________________________ >This email has been scanned by the MessageLabs Email Security System. >For more information please visit http://www.messagelabs.com/email >______________________________________________________________________ >
