‘istenmencs hogy védjem őket, de azért ez egy beta1-es történet, ami majd valamikor 2010-ben fog megjelenni…
Tehát ne várjuk el tőle hogy “”"kész”"” legyen most. Gyerekbetegségek…
Persze ettől még ostorozni kell őket, hogy javítsák ki!

Szerintem várjuk meg hogy mi lesz vele…
Én pl. örülök neki hogy könnyen lehet majd hozzá “add-on”-okat fejleszteni,és hogy “plugin”-elhető lesz.

WinForms lassan már kimegy a divatból, ami végül is nem is baj :))
————

Azzal is egyetértek, hogy vannak melléfogások 3.0-3.5-4.0 irányban, de most ezt a világot éljük…. kidobnak 20 új dolgot, abból 5 hamvába hull, 5 meg teljesen megváltozik mire érett dolog lesz belőle…

De azért vannak okés dolgok is. a módszer meg olyan amilyen… semmit nem tudunk ellene tenni. ez van.

Wrong direction. Azt gondolom, hogy komoly gondok vannak a “.NET moving”-gal. a 2.0 utan mar sulyos tanacstalansag, atgondolatlansag, kapkodas, “tomes” lengi be az egesz .NET vilagot.

Arrol megy a vita szerintem, hogy helyes megkozelites-e az a MS reszerol, hogy pakoljunk bele a nyelvbe, infrastrukturakba amennyit csak tudunk, es bizzuk a fejlesztokre, hogy ok mit valasztanak ezek kozul, dontsenek ok.

Ennek sok veszelye van. Az egyik, ami C++-al tortent, hogy nagyon nehez, osszetett nyelv lett, pilotavizsgas, tulzottan pilotavizsgas. A masik, meg hogy olyasmit teszunk a nyelvbe, ami nem szerencses hosszu tavon, ilyen volt a Javanal a checked exceptions, vagy a a VB6 sulyos konkstrukcioi. Ezek a featureok jonak tuntek elso ranezesre, de hosszutavon kiderult, hogy tobb a hatranya, mint az elonye.

Es szerintem pontosan ez tortenik most a C#-al.

A LINQ használatának feltétele szerintem hogy a programozó képes legyen megkülönböztetni az IEnuberable-t az IQueryable-től, mert nagyon nem mind1…. de lehetne sorolni még…

Tárolt eljárás? Ez ugye vallás kérdése. 5-15 éve beégették az emberek agyába hogy SP, mert nem volt más. Ma már más a helyzet. Ma már hallani azért azt is hogy a SQL server mint neve is mutatja az adatok tárolásáért, kezeléséért felelős, nem pedig az üzleti logikáért. Mármint a teljes üzleti logikáért…

De nem árt amúgy ha a kódernek halmazorientált látása is van, mert enélkül önti ki magából a cursor-t tartalmazó SP-t. Pláne ha ‘asse tudja mifán terem a left join, subselect, indexek és társai.

Őszintén, hányszor láttatok ilyet:
create sp SelectProduct
@1
@2
@3
as
select izé,hozé … from product
left join a
left join b
left join c
where (@1 is null or mezo1==@1) and
(@2 is null or mezo2 loike ‘%’ + @2 +’%') and so on…
go

Na ez hogy vágja tacsra az egészet?!?! ugye…
Mert kezdő, de akár még “átlagos” programozó is előszeretettel csinál ilyet, hacsak nincs valami komolyabb szaki mögötte, mellette…

Igaz ez LINQ-re is.

Én azzal szoktam kezdeni az oktatást, és ezt ismételgetem is, hogy a performancia első feltétele a jól megírt kliens, tökmind1 hogy LINQ vagy ADO.Net 2.0, és az adatbázis ismerete, az indexek ismerete.

Mert ha én kliensben A mezőre keresek, joinolok, és SQLben B re van indexelve, amiről a LINQ _NEM_ tud (nem is kell neki, ez a programozó feladata) akkor szar lesz az egész…

A LINQ általános esetben működik jól, ha spéci az adatbázis/index szerkezet alatta, akkor létéből fakadóan “rosszul” fog működni.
Én anno SQL szakival beszélgettem a LINQ-ről, és nézegettük a profilert.
A kódok alap esetben 100%-osak, a közepes esetben is jóval 90%-osak, és csak spéci esetben volt esetleges hülyeség, amit máshogy írnál meg. De ez sokkal inkább a speciális helyzetből adódott. A LINQ lekérdezés “helyes” megfogalmazásával rá lehet venni a jó megoldásra.
Ezért kell ismerni a LINQ-t mélyebben.
Ha nem, akkor csak móricka feladatokra jó, de nem is állítanak mást…

Visszatérve ugyan azt mondjuk… ha a programozónak se rutinja, se látásmódja, se technikai lexikális ismerete nincs, akkor sz*r kódot fog írni.
De lássuk már be, hogy ez igaz a pascal-tól a c# 4.0-ig…
Csak valami többet, valami kevesebbet enged meg. De ez ‘mér lenne az ő hibája?!?!
Senki se mondta, hogy a c# 3.0/LINQ célja hogy a júzer programozókat ki fogja javítani, és szuper kódot fognak írni…
Miért várjuk ezt el?!?!?

En azt latom/erzem, hogy van egy SQL motor tobb millio dollart olnek bele, hogy okos legyen es az egytalbas insert/update/deletenel tobbet tudjon.
Meg van a c#.
Es vannak fejelsztok akik ertenek mindekttohoz, altalaban persze egyikhez vagy masikhoz jobban ez termszetes, de meg tundak irni egy szerver - kliens cucc mindket oldalat, jo esetben meg azt is el tudjak donteni, hogy az “uzleti logikabol” mit kell levinni SQL odlalra mert sokkal hatekonyabb lesz ott.
Ezzel szemben a fejelsztesek iranya arrol szol, hogy a c#os developer ne ertesen az SQlhez, mert majd ossze rakja helyette a lekerdezest a linq vagy a EF vagy ami majd jon utana.
meg a szintakitkat sem kell megtanulni, mert mas van helyette :)
aztan ha lassu a DB akkor majd a DBA felindexeli… (ezt egy aloadason hallottam…) haaat en ettol fazom :)
szerintem a fejlszto csapat az aki ismeri az alkalamzast oa z aki tudja, hogy mit mivel hogyan fugg ossze, mit hogyan akar megkeresni az adatbazisban ez alapjan az indexek nagyreszet is elroe meg tudja hatarozni. de ha mar azt se kell tdnia, hogy mi az, hogy index es hogy mi is van ha az tirom, hogy join vagy order by, akkor ez nem fog menni.

Hogyan fog a DB programozo guru meg a c# programozo guru (akik majd mar nem fogjak egymas nyelvet beszelni, ismerni) kozos nevezore jutni?

En per pill ezt nem latom a jovokepben (illetve azt latom, mintha az SQL szervert egytablas insert/update/delete kiszolgalova szeretne alacsonyitani a Szep Uj .Netes Vilag. Vagy rosszul latom?

A Binding Source-al meg mit lehet kezdeni a designer szinten? Szerintem semmit, adodoan az XML alapu nyelvbol, es a XAML DataContext koncepciojabol. Szkeptikus vagyok.

Most láttam egy VS 2010-t. Mivel sok minden NDA-s, maradjunk annyiban, hogy amiről beszéltünk (XAML-Binding) az sokkal “okosabb” lett, és “kijavítottak” sok dolgot…
Így már fordítási időben is sokkal több a “segítség”.

Dolgoznak odakint :)

KRis

De itt is ugyan azt mondjuk :) majdnem.

Abban is egyetértettünk hogy ez “lehet” rossz… amikor az általad említett esemény bekövetkezik, vagyis amikor gányolnak.

de gányolni most is lehet nem? cpp-s kód mekkora “gány” már?!?? bizonyos szempontból… nekem pl. az.
ez relatív…

szóval, még azt is elismerem hogy “nagy” az esély a gányra…
De ez kikerülhető… vagy nem?
Képzett, okos kóderekkel, technikai ismeretekkel rendelkező, pontos managerekkel, és architektekkel akik terveznek.
Vagy ez túúúl utópikus volt?!?
Lehet.

Én még hiszek a mesékben :)

no. ez jó végszó erre a hosszú történetre.

A masik oldalrol nezve meg legalabb lesz munkank. :)

“közben megjött a postod a JS-ről….”

Igen, azt atgondoltam kozben. Valoban nem rosszabb, mint a C#-os databinding esetek, ugyhogy azt a hozzaszolasom revidealom.