Jaká je budoucnost Visual Studia .NET?

Jak tak sleduji diskuzi o pristupu k databazim (o cem jinem VS.NET je, ze - hry se v tom psat nebudou ;o))) v VS.NET, tak ze me plyne fakt jen jedno - je v tom HROZNEJ bordel a hromada ruznych komponent s ruznymi vyhodami a nevyhodami a neda s v tom vyznat, takze namisto aby zahodili stavajici zabordelene rozhrani a udelali krasny navrh, tak dopsali jeste jedno, ktere zas taky neumi vsechno... Uaaaaaaaaaaaaa!!!!

Priklad blbyho rozhrani MS - jak mam zjistiti jen pitomy uptime v WinXP? Jako hodne pokrocily uzivatel (ne spravce domeny ani profi programator) jsem to proste nikde nenasel ((( (mozna selektivni slepota, ale...)

To je pravda, rozhranie produktov Mrkvo$rotu je niekedy desne ... a wela sa s tym spravit neda (na rozdiel od linuxu) .. a ta stabilita ... radsej pomlcim. Btw ten uptime v XP: spusti si prikazovy riadok (cmd) a v nom spusti "systeminfo" - uptime je jednou z casti reportu ... Google je tvoj kamarat (postup som nasiel za ani nie 3 minuty

Jo Jo MS je vzdy ten nejhorsi  i kdyz se mu podarilo udelat dost dobrou vec.
Neni to C++ ale Java nebo Dephi. Objektove velmi pekne udelane, zadny bordel. Nejaky programator z Hnojnika(Omlouvam se obyvatelum Hnojnika) to asi tezko muze posoudit, doporucuju aby aspon drzel hubu.
Ale i tak Linux je prece nejlepsi.. v nem jdou prece i ridit jaderne rakety a zvedat prkenko na zachode !!

Právě že rozhraní, zrovna to databázový je přepsané pro .NET od ZACATKU. Funkcionalita DataSetu zahrnuje funkcionalitu Remote data services, MS Persist a MS DataShape Provideru, propojení s XML, multipage a hiearchical ADO Recordset (k dispozici v ADO v. 2.1+) a řadu dalších fíčur, který byly do ADO doplňovaný postupně a implementovaný přes dodatečný vrstavy objektů (ADOX a různý pomocný OLDEB providery). V ADO.NET tu funkcionalitu zahrnuje samotnej objekt DataSet, dá rozum, že jeho objektovej model je trochu bohatší a jeho možnosti si nevyzkoušíte za odpoledne...

Fakt se s tou problematikou napřed seznamte, než tady zase začnete plácat kraviny. Takhle se ta debata se nedá číst...

Stačí vědět, že veškeré info o systému shromažďuje ve Windows objektové rozhraní VMI. V dokumentaci (WMI SDK) pak stačí vyhledat slovo uptime.

For Each oSys in CreateObject("WbemScripting.SWbemLocator").ConnectServer("localhost", "root/cimv2").ExecQuery("Select * from Win32_PerfRawData_PerfOS_System")
  t = oSys.Properties_("Timestamp_Object").value: u = oSys.Properties_("SystemUpTime").value
Next
MsgBox "System uptime : " &  Int((t - u) / 10000000) & " sec"

SARCASM_MODE_ON Jak proste mily Watsone... SARCASM_MODE_OFF

Výše uvedený skript vám umožňuje získat uptime pro všechny stroje v síti. Na lokální stanici stačí použít moniker WinMgmts

With GetObject("WinMgmts:Win32_PerfRawData_PerfOS_System=@")
 MsgBox Int((.Timestamp_Object - .SystemUpTime)/10000000) & " sec"
End With

btw Pod WinXP (ne pod Win2K/NT) pak funguje následující WMI volání, vracející uptime vzdáleného serveru přímo v sekundách :

GetObject("\\123.211.54.32\root\cimv2::Win32_PerfFormattedData_PerfOS_System=@").SystemUpTime

Jak muze clovek, kterej misto DataReaderu pouziva DataSety a nezna XPATH vubec mluvit o vyvoji databazovejch aplikaci v .netu

Od ty doby, co do datagridu nejde jako datasource dat datareader , ale musi tam byt treba DataView:
"Use the DataSource property to specify the source of values to bind to a data listing control. The data source must be an object that implements the System.Collections.IEnumerable interface (such as System.Data.DataView, System.Collections.ArrayList, and System.Collections.Hashtable) to bind to a control derived from the BaseDataList class." coz v mem pripade je ono nestastne DataView. DataGrid, ktery se umi pripojit primo k Readru myslim existuje jako nejaky placeny (nejsem si jistej) ...

Ano je blbost plnit DataView vsema datama pres Fill, ale jinak zase nechodi Pages. Jinak XML je pekna vec, ale jsou tu zase jenom dve moznosti. Bud cely vysledek vylejt do XML a ten pak zpracovavat postupne nebo vylejt jenom onech par radek, ale pak si zase musim delat ten paging sam a to uz je zase stejny mnozstvi kodu, coz je to co jsem od .NET mozna cekal = uspora, ale tu jsem nenasel ani ve vykonu ani v rozsahu kodu...

Pokud existuje nejaky zpusob jak z DB, ktera neni nativne XML nacist par radek + paging pres std. komponenty .NET a zobrazit klasickej vysledek 20 zaznamu na stranku HTML s odkazy na dalsi, predchozi apod. bez oprgavani toho pagingu rucne tak bych fakt chtel vedet jak ?

Podotykam std. HTML co zvladne i Netscape 4.7 takze o prenosu XML na klienta asi rec byt nemuze ... Na netu jsem fakt nic nenasel, ani jeden sample, ale na ten vyse uveden kod s DataView jbylo nekolik samplu vcetne ukazek cachovani ...
Rad si pak nasypu popel na hlavu ...
MiJa

Argumemt s readerem jsem nejak nepochopil, IEnumerable implementuje a tudiz jej lze naprosto bez problemu priradit jako DataSource... A strankovat jde na strane db, nevidim v tom zadny problem ...

Dobry den,
nemohl jsem tento clanek preskocit. Pracuji ve firme, kde delame na vyvoji spec. SW pro Win32, v soucasne dobe pouzivame Visual Studio 6.0. Neco je naprgano ve VB nebo C/C++. Mel jsem bohuzel tu moznost vyzkouset si praci v .NET studiu a nemohu sem nenapsat sve poznatky:
Ano je pravda, ze .NET podporuje vsechny jazyky v jednom prostredi, ale bohuzel nepodporuje vsechny jazyky stejne.

1) Docela podstatna cast veci nejde v VB .NET vubec delat !!! tzn. nuceny prechod na C# nebo C/C++.
2) Doporucovana architektura pro ASPX s IIS se nehodi pro velmi velke projekty s DB, protoze vede bud na nucene pouzivani velkych pametovych cache a nebo potrebuje velmi vyrazne posileni vykonu CPU.
3) Zjistil jsem podstatne omezeni ve vyuzivani starych komponentu napsanych v VS a jejich prenos do .NET - tim nemyslim preklad v .NET to me ani nenapadlo, ale jejich proste vyuziti pres COM rozhrani -> pri prechodu je nutne stare komponenty zahodit ...

Vzhledem k tomuto stavu se nekolika vyvojarum mozna otevrou oci a uvedomi si, ze firma Microsoft se pokousi udrzet velkou skupinu vyvojaru na platforme Windows a v zadne pripade si urcite nepreje, aby vyvyjeli SW multiplatformove - napr. v Jave. Proto za studio .NET firme Microsoft dekuji, nebot je velmi zrejme videt jakym smerem se tato firma snazi prosazovat dalsi vyvoj.
Jeste jeden vtip na zaver.
Odebirame ve firme casopis Visual .NET Journal (nebo jak se to ted menuje drive to bylo myslim Visual Basic journal) - nikdy jsem to moc necetl. A na uvodni strance jsem videl presny obraz toho jak se vse okolo presentuje. Na uvodni obalce byl vyobrazen high-end DB server a u neho dva manici, kteri ho skrtili provazem a bylo to doprovazeno komentarem - v prekladu neco jako: pouzivejte .NET a snizte velikost potrebneho kodu. U toho vyobrazeni jsem se zasmal, protoze me setkani s .NET znamenalo skutecne zkraceni napsaneho codu, ale masinu na ktery by to bezelo stejne rychle jako delsi kod napsany v VS 6.0 bych potreboval tak 4x vykonejsi ...
Takze zaver z toho je, text byl v poradku, ale ten obrazek byl zavadejici, protoze tam meli ty servery spise nakreslit dva ...

LINUXu zdar (zejmena Debianu) a woknum zmar...
MiJa

Docela podstatna cast veci nejde v VB .NET vubec delat !!!

Které věci, například ?

Doporucovana architektura pro ASPX s IIS se nehodi pro velmi velke projekty s DB...

Je tomu právě naopak - současné ASP mají problém s velkými projekty, především s ohledem na organizaci vývoje kódu. ASPX mohou být velice výkonné, mnohem výkonnější než jakákoliv dosavadní technologie pro WEB - ale musí se přitom myslet na více věcí, než doposud - což je u nové generace každ technologie běžné.

Zjistil jsem podstatne omezeni ve vyuzivani starych komponentu napsanych v VS a jejich prenos do .NET...

Jaká omezení, například ? Pod .NET pracuju běžně s DirectX, ADO aj. klasickými COM technologiemi. I když k omezením při práci s nimi skutečně dochází, nejsou tak podstatné, aby znemožňovaly práci s nimi. Ve srovnání interoperability Javy s COM je na tom .NET stále velmi dobře. Krom toho, COM komponenty mají vedle .NET stále svoje pevné místo - a pokusy přepisovat je bezhlavě do .NET nemohou končit dobře. .NET komponenty například nepodporují distribuované transakce a message fronty - jsou určeny pro bezstavové prostředí WWW. Nemohou tudíž nahradit COM 1:1. Síla .NET je úplně někde jinde.

firma Microsoft ... si urcite nepreje, aby vyvyjeli SW multiplatformove - napr. v Jave

A já se vsadím, že firma SUN si určitě nepřeje, aby vývojáři vyvíjeli například v .NET Studiu... A co má být ? Ale .NET FrameWork je od začátku jako multiplatformní budován, a nejen to, je i multijazykový (na rozdíl od Javy) a implementační jádro .NET je k dispozici komunitě jako SharedSource. Uroveň implementace na jiné platformy vychází samozřejmě z toho, že vznikl na platformě Windows. Seznámil jste se už s úrovní projektu Mono ?

A proboha, proč přejete Woknům zmar a současně pro ně vyvíjíte a odebíráte Visual .NET Journal ? To se sám před sebou ani trochu nestydíte ? Jakou úroven má asi Vaše práce pro prostředí, které nenávidíte ? Co Vám brání přejít na místo, kde by jste se mohl věnovat vývoji pro Linux apod. ?

Odpovim jenom castecne, zbytek napisu zitra.

Omlouvam se za spatnou fomulaci, .NET se hodi na velke projekty ale ne pracujici s velkym mnozstvim dat v DB.
1 priklad
- server aplikace, databaze 80000 zaznamu - jiz vyfiltrovanych - zobrazit na html strance 20 zaznamu + pages
a) standartni model - pokazde pri zobrazeni provest cely SQL dotaz - prevod do DataView (vsechny vyfiltrovane polozky) - DataGrid (render 20 fields + pages) - vysledna HTML ==== super CPU
b) cache dle www navodu - cache dataview tzn. filtr jenom pri prvnim zobrazeni - podruhe z cache, ale pro kazdeho uzivatele to znamena 8MB RAM v tahu - to nelze vzhledem k pameti
--- omezeni dotazu na mensi rozsah polozek znamena i manualne generovat pages, kdyz to udelam cely v VS tak pouziji RecordSet se ServerCursor a ten si dam do cache, takze ztrata pameti a vykonu je miziva
Pokud znate lepsi reseni nez a nebo b v .NET byl bych velmi vdecen, ja jsem na nic neprisel ani na I-NETu

Ano stare komponety od Microsoftu jdou pouzivat, ale samozrejme nase firma ma spoustu vlastnich komponent od .OCX pres .DLL az .EXE a tady jsme narazili na obrovske problemy zejmena pokud mam napr. z .DLL komponent pri vyvolavani formularu na konfiguraci danych serveru - obcas je nelze vyvolat apod.

A Woknum zmar z je podle me zcela v poradku. Pracuji ve firme jiz delsi dobu a vzhledem k tomu, ze protlacuji C/C++ tak je mi ve vetsine pripadu jedno pod jakym systemem. Jinak kdyz se me sef ptal jestli mame ten "casopis" odebirat tak jsem mu doslova sdelil (predem se omlouvam vydavateli) ze ten papir je na toaletu zcela nepouzitelny protoze je moc kluzky, takze pro nej nevidim zadne pouziti. Presto byl obednan - z mych penez to nejde takze to ignoruju.
Samozrejme uvaduji o zmene, verejne ve firme prohlasuji ze pokud prejdeme na .NET tak davam okamzitou vypoved. Ale skoro vsude se na Woknech dela a co se tyce studu tak s tim nemam problem, protoze nekdy nesouhlasim s postupy, ktere se pouzivaji jak ve firme tak vne a presto se musim podridit kolektivnimu rozhodnuti.
Jeden priklad:
ma se navrhnou mail server a firewall pro klienta, ja navrhuji linux a odpovidajici reseni, ale vzhledem ke klientovy dostanu prikaz nakonfigurovat Windows+WinRoute - mam snad kvuli tomuhle dat vypoved ? Mam k tomu reseni odpor a hlasite pri tom nadavam, ale presto to nakonfiguruju tak abych se jako zamestanec za to nemusel stydet ....

A jéje. Takže:
a) V klasickém ASP něco jako DataView/DataGrid neexistuje, takže není s čím srovnávat. Tyhle komponenty jsou delane pro urychleni vyvoje, ovsem nic vam nebrani generovat to stejne jako predtim, nebo si napsat vlastni optimalizovanou komponentu - a v tom pripade mate jeste navic moznost vykaslat se na DataSety a nacitat to "on-the-fly" pres DataReader. Coz je v rychlosti uz trosku o necem jinem.
b) viz a), nemluve o tom, ze caching lze dost dobre konfigurovat.
c) Osobne si myslim, ze kurzory pouzivane ve starem ADO byly vhodne pro ISAM databaze, ale v pripade SQL serveru jenom prenasely zatizeni RAM a disku z klienta na server a HLAVNE na sit. Ostatne o tomhle pisou vsechny manualy k SQL serveru, vsude radi omezit se na co nejmensi pocet dotazu do DB a co nejvic veci nacpat do stored procedures. A pokud byste to tahal pres kurzor na klientovi, mel byste to stejne jako u pouziti DataSetu, cili opet pamet v haji. Podle meho je lepsi tohle resit pomoci TransactSQL a stored procedures, za pouziti temporary tabulky neni tak velky problem to udelat, vykonove to je prinejmensim stejne jako u kurzoru, ale spise lepsi. Jenom to chce trosku myslet. Abych byl uprimny, nejvic se mi libi konstrukce pouzivana u MySQL (ted si nepamatuju klicove slovo) nahrazujici TOP keyword u MSSQL, kde se urcuje krome poctu zaznamu i offset. MSSQL by tohle melo umet v pristi verzi. Mimochodem, kdyz uz vyvijite na MS platforme - na Emwacu je par newsletteru, mj. jeden i o VS.NET. Uz se to tam take probiralo...

Co se tyce komponent - nejak nechapu, co tim chce basnik rici; vy pouzivate formularove komponenty NA SERVERU? Hmmmmm.......

Cili abych to shrnul - .NET se hodi na velke projekty s velkym mnozstvim dat v DB, ovsem je orientovany na client-server databaze (v souvislosti s nativnimi ovladaci zatim hlavne na MSSQL), kde neni reseni pomoci kurzoru vhodne; paradoxne tak prenasi nutnost vyresit strankovani na programatora, ale neni az tak velky problem to zvladnout, moznosti jak toho dosahnout je vice, pokud chcete, muzu vam poslat ukazku.

Ja nevim ze se trapite odpovidat... do techto for na zive.cz pisi vetsinou pouze nimralove co nikdy nenapsali nic jineho nez databazi CDcek a nebo "odbornici" z nekterych vyvojovych firem. Lide, kteri travi cas praci a sebevzdelavanim nenapisi 3 odstavce kydu o tom jak je VS.NET a .NET Framework na nic... 

Také se občas sám sobě divím.

"nejvic se mi libi konstrukce pouzivana u MySQL (ted si nepamatuju klicove slovo) nahrazujici TOP keyword u MSSQL, kde se urcuje krome poctu zaznamu i offset. MSSQL by tohle melo umet v pristi verzi. "

k tomu chci jen rict, ze mySQL neni klasicky db stroj ale je to na zaklade ISAM. MSSQL tohle v pristi verzi umet zcela jiste nebude, protoze je hlavne zalozen na praci s mnozinami, coz tuhle moznost vylucuje. (a pokud by to tam bylo tak by to muselo byt vnitrne resene pres cursory, tmp table apod.. coz by bylo z hlediska vykonu bylo stejne na prd.).

Nevím, odkud čerpáte svojí jistotu - já mám tuhle informaci od pana Jurka z Microsoftu (abych byl ještě přesnější, zazněla v tom mnou zmiňovaném newletteru na Emwacu). Na to nemusíte přece používat temporary tabulky, stačí při načítání záznamů posílat klientovi data od x-tého záznamu a ty předchozí prostě ignorovat. Pořád takováhle smyčka bude rychlejší než kdyby to někdo cpal do další tabulky, kde by se ta data musela načíst taky. Netvrdím, že MS to bude dělat takhle, ale tohle je podle mě nejjednodušší řešení.
Možná tomu ale rozumíte líp...
Máte snad přístup k informacím o vývoji, k betavezím...? Nebo jenom tak plácáte, aby řeč nestála?

Tohle v SQL už dávno (SQL v. 7.0+) a nativně řeší kurzorovej engine, resp. skupina procek sp_cursor****, používanými např. ADO.
Není problém fetchnout sadu záznamů od čísla N... U procek je k dispozici zdroják, můžete se podívat jak to dělají (interně využívaj serevr-side kurzory)

Prostudujte si SQL Server Books, popř. dokumentaci na inetu.

Jo, jenze za jakou cenu. SQL server je, jak uz tady kdosi podotknul, delany primarne na praci s mnozinou zaznamu, kurzory byly pridany jako jakesi rozsireni pro vyjimecne situace (doporucuji popis historie kurzoru v knize Mistrovstvi v SQL serveru 6.5), ale jejich pouzivani s sebou nese dost slusnou rezii, protoze vas navrh znamena pouzivat staticke dynamicke nebo keyset kurzory; v prvnim pripade se vam VSECHNA data cpou do temporary tabulky, v druhem pripade se pri kazdem fetchnuti dela opetovny dotaz do databaze, ve tretim pripade se vam cpou VSECHNY primarni klice do temporary tabulky a pri kazdem fetchnuti vam SQL server znovu hleda prislusny zaznam podle primarniho klice. Cili ve vsech pripadech to je po vykonove strance dost na houby, zvlast pokud delate s vetsim mnozstvim dat. Zkousel jsem si i testovat co se stane, kdyz udelam fast forward kurzor a prvnich n polozek proste preskocim - ale ta smycka v T-SQL prece jen nebyla nijak rychla, to uz bylo lepsi pouzit kurzory ve vasem pojeti. Osobne preferuju ciste T-SQL bezkurzorove reseni, jde to udelat - ale pokud by to nativne podporoval SQL server, bylo by to rozhodne lepsi, clovek by se obesel bez temporary tabulek.

Prave z duvodu nadmerneho pouzivani kurzoru je podle meho v ADO.NET MS vypustil, proste lidi pouzivali neco, aniz by vedeli, co se diky tomu deje na pozadi, a pak jim s pribyvajicimi daty klesal vykon takrka exponencialne.

Ted me jeste napadlo - tohle vlastne uz do jiste miry umi MSSQL uz od doby, kdy podporuje dynamicke kurzory, akorat ze nevraci sadu zaznamu nybrz jen jeden: dynamicky kurzor totiz pri kazdem fetchnuti znovu sestavi vyslednou mnozinu dat a z ni vybere zaznam na prislusne pozici. Cili by slo "jen" o to, aby to bylo schopne vracet krome toho jednoho zaznamu jeste tech x zaznamu za nim...

tady bych napsal jeden poznatek, pokud udelam databazi, ze veskera logika je na strane servru - stored procedures atp, tak je mi uplne jedno, jetsli pouzivam OLEDB, ADO a nebo to staricke a "spatne" ODBC.
OLEDB a ADO jsou tady pouze proto, ze migrace Accessovsky aplikaci na SQL server byla nehorazna. Kdyz byl formular navazan na view do tabulky na servru a chtelo se posunout o zaznam nahoru, tak se refreshoval na zaklade selectu cely vyber a ne jen extra radek. Nejhorsi vsak bylo, pokud jste nemohli delat pass trough queries, tak pak vas bandwidth sel do prdele, protoze sepo siti posilala cela tabulka. Tohle prave mel resit OLEDB s tim, ze mel neco jako "maly" DB server v sobe a reposilalo se pouze tehdy, pokud byla originalni tabulka zmenena. Nastesti praxe ukazala, ne navrhy IS ve stylu Access je pouze masochizmus a tak se zas vraci ke skutecnym 2 nebo 3 vrstvym C/S aplikacim.

V cem je sila .NETu? Mluvi se o Office.NET, MSSQL.NET. Pokud je .NET urcen pouze pro WEB, tak jak si vubec nekdo dovoli srovnavat s Javou.

PiseteA já se vsadím, že firma SUN si určitě nepřeje tak to by ste prohral, protoze firme SUN pouze vadi, kdyz nekdo meni zakladni API JVM. Jinak je hodne OOS projektu implementujici JVM, je tady IBM. No a SUN ma problemy pouze s M$, cim to asi bude? K mono si trosku zabruste vys, co jsem odepisoval, jednomu cloveku. Doporucuju precist nejake diskusni boardy, abyste byl aspon trosku v problematice.

A posledni vec, proc by mela Java spolupracovat s COM? Zamyslete se, co je to COM a co Java. Pak pochpite, ze jste vedle. Btw uz bych se radsi bavil o Beansech.

window.open=PrxRealOpen;
Záměry jsou pěkná věc, ale stejně to nakonec bude všecko jinak. Třeba se ukáže, že ten slavný .NET je na desktopu asi tak dobrý jako Java, takže v tom nikdo nic vyvíjet nebude a Microsoft to pohřbí... nebo bude mít někdo u MS zas nějaký jiný geniální třicet let starý nápad, tak se pustí jiným směrem... pche, tyhlety plány na x-let dopředu jsou úplně nanic.

Mno vidim ze promluvil dokonalej manager a ekonom v jednom. Mas pravdu je fakt lepsi firmu vest ze dne na den, presne takovou strategii bych ti doporucil jestli si zalozis firmu a uvidime jak dlouho s ni vydrzis...

Ano, taky jste se tak strasne tesili na to jak dot net bude vyborne pracovat s naprosto pokrocilou technologii MS Passport a jine "supermoderni" komponenty.

Ano, taky jste se tak strasne tesili na to jak dot net bude vyborne pracovat s naprosto pokrocilou technologii MS Passport a jine "supermoderni" komponenty.

A on s ní snad nepracuje ?

MS .NET Passport je WEB service jako každá jiná a úroveň práce s ní je ve .NET Framework zcela standardní. Zřejmě vůbec nevíte, o čem plácáte - jste obyčejnej spammer.

...az na to, ze lidem se nechce Passport pouzivat a neveri MS... a jinou volbu jim MS nedava, takze nekdo to prekousne a nekdo bude hledat jinou variantu (Linux ;o)))

navic MS prichazi kazdy 2-4 roky s novou strategii na dalsich 5 let :o) - jen kolik je ve VB 6.0 pristupu k databazi - myslim asi 4 naprosto odlisne zpusoby... (((

Trochu si odporujes. MS Passport je jediny a nadavas. Databazovych pristupu je nekolik a nadavas. Myslel jsem, ze jen zensky (noflame) nevedi, co chteji.

A dale: kolik si myslis, ze je databazovych pristupu v Delphi? Mnohem vic a nikdo si nestezuje, naopak by rad jeste nejake. O co ti jde? Jen o nadavani na uspesnou firmu?

MS Passport - nadavam na netransparentnost protokolu, nemoznost postavit si vlastni server a byt plne zavisly na MS, co s tim udela, a taktez jeho ochrana dat a soukromi je dosti na povazenou. (viz treba akce BSA, agreementy k Passportu apod). Je to krasna idea - prihlasit se jen jednou - ale to umi treba Kerberos.

Datove pristupy - vadi mi, ze neustale kazdych par roku prida neco noveho, aniz by to opravdu melo nejake racionalni duvody (aby ty featury nesly pridat do stavajiciho rozhrani) a musis prekopavat cely aplikace, protoze ty stare komponentny najednou nejsou tak kompatibilni, jak jine ;o)

Rozdil myslim jasny.

Passport: Představ si reálně, co by se stalo, kdyby MS data prodal, ztratil nad nima kontrolu či něco podobného. Pak by mohl jít louskat ořechy. Velmi pěkně o tom mluvil loni David Chappell.

Datové přístupy: to je naprosto normální vývoj. Prostě technologie zastará (ODBC), tak tu bude jiná, lepší (ADO). Tak je to i s přístupy. Tu je nativní driver, tu je ODBC driver, tu je OLE DB provider. MS navic podporuje prevazne sve datove pristupy. Borland Delphi podporuje nejen MS, ale i ostatni vcetne sebe sameho. To neni nic nenormalniho. A pokud invoujes vyvojove prostredi, musis inovovat i zdrojaky.

Predstavuju si to realne: http://www.theregister.co.uk/content/4/26590.html

aby ty featury nesly pridat do stavajiciho rozhrani...

versus

...pri prechodu je nutne stare komponenty zahodit ...

nebo

...namisto aby zahodili stavajici zabordelene rozhrani a udelali krasny navrh, tak dopsali jeste jedno, ktere zas taky neumi vsechno...

Chápete, že jeden chce po Microsoftu pravej opak toho, co druhej a třetí ... ???? Ale ani jeden neni spokojenej s tím, co dostal (v podobě ADO.NET de-facto zdarma)....

...v tom nikdo nic vyvíjet nebude a Microsoft to pohřbí....

.NET na desktopu se od Javy odlišuje jednou věcí, a tou je výkon. Dobře napsaná aplikace v .NET je výrazně rychlejší než Visual Basic - a to i za předpokladu, že je celá tvořená managed code. Analogicky rychlou aplikaci napíšete jen v Native Java. Začleněním (mimochodem zcela transparentním) unmanaged kódu v C do .NET aplikací získáte plnou rychlost C++ - při nesrovnatelně flexibilnějším a pružnějším obejktovém modelu, mnohem snazší a formalismem Javy nezatíženou prací se systémovými objekty, dialogy atd...

Další nezanedbatelnou výhodou .NET oproti Javě je multijazykové prostředí (už dnes můžete v .NET vyvíjet zcela srovnatelné aplikace v C, JavaScriptu, Basicu, Fortranu, Javě, Cobolu.. - no to je přece skvělé, ne ? Tahleta flexibilita se mi zvláště líbí - zpřístupňuje rozhraní .NET všem vrstvám programátorů - od oněch "trapných" basicářů po ostřílené OOP vlky. .NET vás na rozdíl od Javy nenutí, jakým style m v něm budete programovat - je v něm prostor pro vývoj drobného špagetového kódu v notepadu i pro korporátním style m vedená rozsáhlá aplikační řešení se sdílenými knihovnami a třídami kódu na kompilované i nekompilované úrovni s přesnou strukturou dokumentace a vzájemných závislostí.

Nakonec něco osobního: Zatímco vy jako typický malý český hospodský človíček naříkáte, Microsoft se činí - nedivte se, že za svoji práci bude brzo sklízet ovoce, o jakém se vám ani nesnilo.

ad při nesrovnatelně flexibilnějším a pružnějším obejktovém modelu) aha hm nehlede na to, ze flexibilni a pruzny je totez, by mne zajimalo v cem je reprezentace .NET objektu jina, nez u Javy. Nebo mluvi o C++? Hmm a zacleneni C++ do javy nelze? K cemu pak je JNI?
ad formalizmus) chlapce, bezpecne techniky programovani jsou utopie, co?


ad Další nezanedbatelnou výhodou .NET oproti Javě je multijazykové prostředí (už dnes můžete v .NET vyvíjet zcela srovnatelné aplikace v C, JavaScriptu, Basicu, Fortranu, Javě, Cobolu.. - no to je přece skvělé, ne ?) odhledneme od toho, ze srovnavat lze pouze Javu a C#, zamyslime se nad vyznamem .NET. K cemu to u Windows je? Mam vsechny jazyky, ktere mi prekladaji do nativniho kodu. Multiplatformnost u .NET nehrozi, takze vkladame zbytecne jednu vrstvu mezi aplikace a system. Hlavne, ze je to podobny Jave a to je IN, zejo )

jo jeste jsem zapomel na Javu a rychlost, pan urcite netusi, co to je JIT Diky tomuhle jsou pripady, kde Java je rychlejsi nez nativni C

Multiplatformnost u .NET nehrozi

vazne ? mono, dotGNU-portable.net

mono uz dneska bezi, problem je v tom napsat vsechny ty knihovny

a co treba multiplatformnost co se tyce procesoru ? to je dulezite (IA64, x86-64)

nemluve o tom ze dynamicky kompilovany kod ma vyssi vykonnostni potencial nez staticky kompilovany

ne multiplatformost vazne nehrozi - mono uz melo byt hotove pred pul rokem a slovy jeji tvurcu -nikdy se nebude portovat cely NET...
-ano je to prekvapive ,ze systemy MS ze dokazou pracovat s ruznymi druhy procesoru... :))))))))))) spoctete si kde vsude bezi java.:))))

bezi, ale JAVA a multiplatformost je taky ponekud utopie. Staci JAVE zmenit jenom procesor z AMD na P4 a jde to do kytek. Nedovolim si odhadnout, jak by to dopadlo, kdybych zmenil behem vyvoje dokonce cele JDKcko - treba 1.3 -> 1.4.

Zase dalsi M$ FUD kec. To by me zajimalo, co polozi Javinu kdyz pustis nejaky tridy na AMD a na Intelu. A kdybys zmenil JDK ? Existujou pomerne velky projekty, ktery jsou schopny behat jak na JDK 1.3 tak i na 1.4 a behaji v pohode na Woknous, na Linuxu, na Solarisu, na Macovi a dokonce i na VMS . Jsem zvedav kdy tohle bude umet ten .NET. Zrovna jsem se dneska dival na www.go-mono.org - moooc pekny - dokonce se chlapci umej uz zkompilovat. To je docela dobrej vysledek (to nemyslim ironicky). Bohuzel jsem zvedavej co budou delat z WinForms a dalsima vecma jako je MTS a tak .....

A to jste zkousel, nebo jste na to prisel jak? Hot-plug z AMD na P4  ?

Uplne bezne to beha na Linuxu, Windowsech, Solarisu, od PIII na 500, po P4, pres Athlona, az po UltraSparc a nikdy se nam nic podobneho nestalo.

mono nikdy nebude podporovat 100% .NET API z Woken. Vyjadrili to jak tvurci Mona, tak M$, ktery si hned vyhrazoval Intelektualni vlastnictvi na urcite partie. Ve vysledku se dostaneme tam, kde je momentalnie IE. Vytvoris stranku pro IE nebezi nikde jinde. Vytvoris stranku napr. v mozille bezi vsude.

Mate pravdu leda v tom, ze standardne napsana aplikace je v .NET rychlejsi nez standardne napsana ap. v Jave (JNI a JIT ponechme stranou). A zbytek uz je jako letak MS:) Nevim v cem by mel byt objektovy model .NET flexibilnejsi, pokud hlavni jazyk .NETu (C#) je jako kopie Javy - popravde bere Javu jako zaklad a pridava do ni to dobre z C++. Multijazykove prostredi je mi docela na nic, pokud .NET bezi _jenom_ na platforme, pro kterou jsou kompilatory a vyvojova prostredi jednotlivych jazyku dostupna samostatne. Samozrejme neni jazyk jako jazyk, a tak clovek po case zjisti, ze pro plne vyuziti .NETu musi prejit na C# - IMHO je cele tohle multijazykove prostredi jenom (jako obvykle genialnim) marketingovym tahem na pritazeni vyvojaru v jinem jazyce. A kazdemu je myslim jasne, ze .NET nikdy nebude bezet na jine platforme nez na WIN, takze multiplatformni tenhle pocin od MS urcite nebude, ze:)

BTW, ja nechci kritizovat Visual Studio .NET, uznavam, ze je to urcite vic nez dobry nastroj pro win-only aplikace a obzvlast nejake ty desktopoviny, ale urcite to neni to, co se z .NET MS snazi udelat.

kazdemu je myslim jasne, ze .NET nikdy nebude bezet
na jine platforme nez na WIN

az na to ze jadro .NET *uz dnes* funguje na BSD i Linuxu

A co je v tomhle pripade jadro???

kompiler C#, runtime ("JVM")

proste jim to celkem normalne bezi, akorat maji jen cast knihoven

Nojo, jenomze pouzitelnost jazyka tvori prave ty knihovny a to bude kamen urazu. Kompilator jazyka je vec jedna, ale zkuste si neco udelat treba v Cecku bez knihoven, nebo v C++, nebo jinde.

Aha, bez knihoven, uz jsme u toho:) Bez knihoven bych toho moc neudelal, a kdyz si vezmete, jak je .NET provazany s WIN platformou, tak moc neverim tomu, ze to proste nekdy bude plnohodnotne prostredi. Spis bych to videl na dalsi marketingovou pikosku, ktera ma pritahnout vic a vic vyvojaru...

pozri zober si to tak, ak ides vyvijat nejaku aplikaciu tak mas linux v riti, lebo aj tak ho poziva zanedbatelne percento "uzivatelov" ktory si tvoju aplikaciu aj tak nekupia :)

Jestli mas linux v riti, toz te uprimne lituju, doufam, ze je to alespon jen nejaka minidistribuce

Linux v riti nemam a nemam v ni ani Winy, ani BSD, ani Solaris a ani zadny jiny OS, protoze pokud to jde, delam aplikace co nejvic multiplatformni - kdyby to v .NETu slo, byl by to urcite dobrej produkt. Jinak jenom tak BTW: argumentovat tim, ze linux pouziva malo lidi je IMHO celkem amaterismus, protoze kdyz mluvim o vyvoji pod linuxem, resp. unixem, vetsinou jde o _serverove_ aplikace. Urcite se shodnem na tom, ze zastoupeni unixovych OS je na trhu se servery vyssi nez zastoupeni WIN, takze kolik end-useru pouziva linux je mi docela jedno. Pochopitelne kdyz k serverove casti delam klientskou cast, budu se snazit, abych nevyskrtl uzivatele kvuli tomu, jaky maji OS.

jenze ja mluvil o tom co uz je _dnes_, ne co je 100% mono, chapes?

Hmm, jenze to co je mono dnes je naprosto nepozuitelny pro nejaky projekty (a to podle me ani pro fazi experimentu). Proste jsem na ten .NET zvedavej, jak si povede do budoucna. BTW minuly nebo predminuly mesic sam Bill Gates tvrdil, ze .NET se neprosazuje tak jak ocekavali. A diky tomu byly provedeny nejake personalni zmeny. No, snad se nebude prosazovat ani dal .