Marcival újra összeállunk pár akcióra, ennek első megnyilvánulása, hogy újra lesz Design Patterns tanfolyam.
Már írom át az anyagot, a 3.5-ös .NET Fw. tele van szebbnél-szebb design példákkal, illetve az utóbbi 2 év gyakorlati programozása során jó pár dolog tovább formálódott, tisztult a fejemben, ezeket is beépítem az anyagba.
A referenciáim között megtekinthető, hogy volt, amikor cégek szinte összes programozója részt vett a tanfolyamon, felismerve a dolog hasznát a fejlesztési folyamatok minőségére.
És végül, aki bemásolja a következő kódot a jelentkezési lapjára, 20% kedvezményt kap a tanfolyam árából:
public class DP: Course, ISupportDiscount
{
public HappyStudent GiveMeThisDirtyGoodCourseCheaply() { }
public string Author { get { return “soci”; } }
public string Trainer { get { return “soci”; } }
public DateTime ActionTime { get { return DateTime.Parse(“2009.03.09”); } }
}
Szeretettel várok mindenkit.
Could you hire me? Contact me if you like what I’ve done in this article and think I can create value for your company with my skills.
LEAVE A COMMENT
46 COMMENTS
Le a Linq-val, le a var-al, es le az extension methodokkal.
?
Mesélj. :)
Alapvetoen mindegyikkel ugyanaz a bajom: rontja a kod megerthetoseget nagy projekt kornyezetben.
Csak egy pelda. Az, hogy nem explicit az a pont, ahol a Linq query valoban az adatforrashoz fordul, az enterprise kornyezetben nem elony, hanem hatrany. Az tevedes, hogy nem kell tudnod, hogy pontosan mikor fut le. Kis hazi projektekben, meg a 101 sample-ban talan igy van. Vagy az sem explicit, es szinten nagyon zavaro, hogy mikor valt at linq-to-sql-rol linq-to-objects-re a feldolgozas. A deklarativ/funcionalis nyelvek fele elmozdulas egyszeruen nem illik az enterprise kornyezetbe, mert tul tomor lesz a kod, es egy csomo aspektusbol elvesz hasznos informacio.
Az szokott az erv lenni a deklarativ fetureok mellett, hogy a legfontosabb (domain) tudast lehet vele letisztultan, sallangok nelkul megfogalmazni. Csakhogy enterprise kornyezetben, ahol minden osszefugg mindennel, nincsen olyan, hogy sallang.
Szegeny Heljsberg, tokre szembe lehet allitani a mostani pdc eloadasat a par evvel ezelotti nyiltakozataival. Par eve meg azt nyilatkozta, hogy nagyon-nagyon ovatosnak kell lenni egy-egy nyelvi featurenek a nyelvbe bevezetesevel. Ugylatszik, hogy a corporate ervek legyoztek.
Hááát…. nem tudom… ennyire biztosra kijelenteni.
Leszögezem én abban az értelmében nem vagyok enterspájz programozó, hogy ultra-giga programokat fejlesztenék, ami mega vállalati környezetben fut….
tehát így nem abból az aspektusból gondolkodom, hogy jó vagy nem… ki tudja.
Másodszor visszafelé kompatibilis minden, nem kell/kötelező használni. Amit úgy érzel hogy számodra inkább – mint +, azt ki kell hagyni.
Céges policy, oszt jóvan…
Amúgy véleményem szerint a fenti példáid csak felfogás és megközelítés kérdése. Ha kvázi minden programozó (legalábbis akinek köze van hozzá) érti, ismeri azt amit leír (nem egység-mókus-programozó 1 hónap gyakorlattal, NEM bántásképp!!!), akkor nem lehet probléma…
Pl. eddig is voltak delegatek, amikkel dolgozgattál, és ki tudja mikor hajtódott végre. Sőt. Az egész c++ arról szól hogy függvény-pointer-listákkal folytatsz véres harcot, és egyszer csak meghívod.
Itt is ott is van deklaráció, értékadás és van konkrét végrehajtás, és ezek között tér-idő távolságok vannak.
Valóban itt ránézésre lehet kicsit nehezebb megállapítani hogy mikor következik be a végrehajtás (FV hívás nyilvánvaló), de ez kis rutinnal elsajátítható…
———
Ezek a dolgok bár látszatra egyszerűek (C# 3.0 + LINQ ficsörök megérthetők 2 óra alatt), de sok következménye van, és ami fontosabb szakítanak több 5-10-X éves “dogmákkal”… Kell egy kis idő hogy beérjen, és ugyan olyan alap dolog legyen, mint a mostani dolgok.
—
KRis
“Pl. eddig is voltak delegatek, amikkel dolgozgattál, és ki tudja mikor hajtódott végre.”
Igen, es azoknak a tulhasznalata is mindig rossz programozoi gyakolat volt.
:)
Valóban, azt nem lehet tagadni, hogy bizonyos értelemben sokszor nehezítenek dolgokon (pl ezen új ficsörök). Ilyen a debug is.
Az érthetőséggel kapcsolatban már kétségeim vannak (mármint hogy nehezítene), persze van amikor igen, de itt árnyaltabb a kép.
Viszont. Rengeteg dologban viszont segít, ill sok a pozitív dolog is.
Produktivitás, absztrakció, sebesség, új lehetőségek, stb…
El tudok képzelni egy ilyen beszélgetést…
“Programozó”: Ha így kódolom “konzervatív” megoldásokkal 10 egység, ha meg ezzel a megoldással akkor 7 egység. Bug persze mindkét esetben lehet de második esetben valószínűleg nehezebb lesz megérteni/javítani mert… Maradjunk az első megoldásnál…
“Manager/Megrendelő”: dehoooooogyis, miért fizetnék 10egységre mikor 7 alatt is megoldható?!?
“P” : jó jó, de minvanha…. én szoltam
“M/M” : ok ok. lehet hogy igazad van, de akkor majd javítjuk nehezebben. De ha bejön akkor nyertünk 3 egységet….
Na ha itt az egység 1000 emberóra, sok ezer forintos óradíjjal, akkor lehet az akármilyen enterspájz dolog, B megoldás kerül választásra…
Vagy nem?!?
——–
Sokszor láttam/hallottam, mint ADO.Net/LINQ oktató, hogy úgy állnak neki éles rendszerben használni a LINQ 2 SQL-t, hogy 1. azt hiszik ez MAGA a LINQ, 2. azt hiszik ez a következő über megoldás, és most azonnal le kell cserelni mindent 3. nem ismerik az egész 10%-t sem.
Sarkítottam, de ‘azthiszem érthető…
Ilyen esetben persze, hogy bugos lesz a projekt, és architekturálisan egy nagy rakás…. és 1 év múlva újra kell írni…
Ebből azt akartam kihozni, hogy minden technológiát ARRA, és csakis arra kell használni amire kitalálták. Ha ez nem felel meg az igényeidnek, követelményeknek, akkor ne használd.
A LINQ 2 SQL —NEM—- enterspájz megoldásokra lett kitalálva, ez csak egy lehetséges alkalmazása a LINQ-nek, amit a provider alapú megközelítés biztosít. Pl. LINQ 2 SQL nem lesz a következő 2-3 évben továbbfejlesztve….
—
KRis
KRis, nem igazan cafoltad a velemenyem, ha jol latom, sot, te is azt mondod, amit en?
A “rengeteg dologban segit” meg “sok uj lehetoseg” kifejezesek nem tul sokat mondoak :)
En a C# 3.0 featurejeit kiserletkent latom, a MS bedobalja az uj technologiait a kozossegbe, aztan figyeli, hogy melyik valik be. Te magad is ezt tamasztod ala, valoban a LINQ2SQL nincs a fokuszban, most eppen az EF-re vetul minden feny. De nezz csak korbe a forumokon, hogy milyen sulyos elvi problemakkal (amik aztan katasztofalis perfomanceban nyilvanulnak meg) kuszkodik a LINQ2Entities. Az Entity Framework query resze maga a katasztrofa.
Nem tudom, hogy kinek az erdeme, de osszeteszem a ket kezem, hogy a LINQ hasznalatahoz muszaj usingolni a linq namespace-t. Igy szerencsere konnyen policybe teheto, es ellenorziheto, a LINQ hasznalatanak tiltasa. Szerencsere a dynamics is ilyen lesz.
Ok, neked mint oktatonak biznod kell benne, hogy a tanitvanyaid jol hasznaljak majd ezeket a featureoket. En viszont tudom, hogy nagyon kevesen lesznek/vannak ilyenek.
Egy bizonyos szintig a technológia és a technológia készítőjének “hibája”?!? az hogy nem úgy használják mint ahogy kitalálják, de nem végletekig.
(megjegyezném hogy ezek a dolgok egyrészt dokumentáltak, másrészt nem kell fejest ugrani mindenféle előkészület nélkül, hanem előtte körbe kell járni, izlelgetni, tesztelgetni, és csak ezek után éles projektben használni)
Ha úgy érted, hogy egyetértek, hogy akkor nem szabad használni egy technológiát ha nincs mögötte hozzáértő szakember, aki tudja mit miért tesz, akkor igen! osztom a véleményed.
Mint ahogy buszt se adunk annak a kezébe aki csak szgk.t tud vezetni, ha a vezetést nézzük…
ekkor jobb ha közelébe sem engedjük…
Node, ha így gondolkodna mindenki, hogy ne fejleszzünk ki dolgokat, mert majd minden 2. programozó cseszik megtanulni rendesen (ön vagy nemönhibájából-> nincs pénz a képzésre), vagy rosszabb esetben rosszul használja, akkor hol tarta az egész?!?!
procedurális pascal környékén max sima C, vagyis ott ahol az egész “programozásdi” elvi, konzervativ alapjait lerakták (és ezt nem rossz értelemben írtam).
Véleményem, és nagy szakik, profok, nyelvkitalálok szerint pl a C# egy igen inventiv, modern nyelv. Ebből kifolyólag sokkal messzebb van az igazi OOP-től mint pl. a JAVA.
Hogy ez jó van nem jó?!? Döntse el mindenki. Szerintem jó és szükséges.
—
Valóban lehet egy érzése az embernek, hogy nem minden tökéletes ezekkel az új ficsörökkel kapcsolatban…
Ők is emberek, ők se láthattak mindent.
Miért várunk tökéleteset tőlük?!?!
mutass egy másikat ami legalább annyira kopmlex, értsd PLATFORM (tehát nem csak egy apró kezdeményezés) mint a .Net, és nincs legalább ennyi hibája…
Amióta megjelent a LINQ (2 object) azóta használom, nem keveset, sokat. Mert jó. semmi olyat nem tapasztaltam vele kapcsolatban mint te. Igaz nem enterprise megoldásban mozgok…
De továbbra is azt mondom hogy az nem a technológia hibája, ha a kódmokusok (NEM negatív értelemben!!!!) nem értik…
Hasonlóan WPF. Hát már 10 éve így kellene csináni! Olyan megoldások vannak benne, hogy az ember agya kettéáll! És nem azért mert rossz, ellenkezőleg!!!
Elcsépelt, de a WPF tanulási görbéje igen-igen lapos az elején… majd meredek, és megint lapos… ERGO 2 hét bütyköléssel sehova se lehet jutni. Ez azért van mert szakít rengeteg DOGMÁval.
És bármennyire úgy tűnik WPF igen is enterspájz. Csak érteni kell hozzá lásd CAG, PRISM, MVVM.
Hasonlóan EntityFramework…
—-
Félreértés ne essék, nem védem és nem is tisztem védeni ezeket, csak sok oldala van…
Amúgy vigyázni kell, hogy mit NEM akar/hajlandó tanulni/használni az ember. Teccik nem teccik robog a vonat, nem kötelező felszállni.
Most csak 2-3 céggel konzultáltunk hogy vann nekik VB1-6/ Win32/MCF kódjuk egy rakat… meg rá épülő megoldás.
És azt mondogatják hogy kezdi ellepi őket a….megeszi őket a piac.
Ilyen lesz hamarosan a VB utáni és .Net 3.5 előtti technológia is…
Na jó lehet a 2.0 előtti…
Üdv,
KRis
KRis, kulcsfontossagu egy nyelvnel, hogy mi az ami explicit es mi az implicit kell/van kifejezve benne. Minnel tobb minden explicit, a nyelv annal “bobeszedubb”, annal tobbet kell gepelni. Minnel tobb miden implicit, a kod annal tomorebb lesz, de ezen kivul meg egy csomo kovetkezmenye van. Minnel nagyobb egy projekt, annal jobban erzekelteti a hatasat a kod tomorsegenek mellekhatasai.
Azt mondom, hogy nagy projekteknel a var-ok, extension methodok, anonymous typeok eseteben mar meghaladja a mellekhatasokbol szarmazo hatranyai a kontrukciok elonyeit.
Alapvetoen a LINQ-val is ez a bajom, tul sok minden implicit. Olvasol valami ismeretlen LINQ kodot, es csak gyulnek a kerdesek benned.
jav: …kulcsfontossagu egy nyelvnel, hogy mi az ami explicit es mi van/mit kell implicit modon kifejezni benne…
Értem én ezt.
Ettől függetlenül (sok) minden e felé tendál…
WCF: dekleratíve leírod-> kinyilatkoztatod milyen módon akarsz kommunikálni, s lőn. Lehetne tcp csatornákat is nyitogatni, és byte packeteket küldözgetni, mert ott úgy érzed, érezheted hogy kezedben tartasz mindent… vagyis minden úgy és akkor történik amikor/ahogy TE akarod…
(persze ez sarkos)
Jó,vagy rossz ez most akkor?!?
Igazat adok hogy egy bonyolultabb LINQ első ránézésre, egy “kezdő” számára nem egzakt. De egy profi számára igen.
Továbbá az általad említett késleltetett végrehajtás előnye hogy egy queryt több lépésben is össze lehet állítani, az egyik kimenete lesz a másik bemenete. közben a memoriában alakulgat a tree, és mindig optimális…
Ezt én gyakran követem közepes vagy nehezebb query-knél. Megtehetném hogy egybe leírom 10 sorba…
Persze ez megint az amit te negatívumként emlegetsz…
Aztán meg sok olyan alap feladat van amit LINQ nélkül 2-3 függvénnyel/delegattel, rakat switchel, iffel oldottál meg. LINQ-el meg 2 lamda, extension, és 3 sorban megoldottad. Úgy hogy ránézésre sokkal többet mond a LINQ.
Szóval van az érmének egy másik oldala is, amikor igen is sokat egyszerűsít.
De igazat adok a másik oldalnak is. Csak én úgy gondolom, hogy az tanulással, rutinnal ellensúlyozható.
KRis
KRis, nincsen ingyen ebed.
Gyerekek, éjszaka megpróbálom végigolvasni az okfejtéseteket, ez durva. :)
“Szóval van az érmének egy másik oldala is, amikor igen is sokat egyszerűsít.”
Persze, sokat “egyszerusit”, legalabbis tomorebb lesz a kod, de pont azt mondom, hogy ezaltal evesznek olyan aspektusai a kodreszletnek, ami nem szerencses, mert csunyan rontja a megerthetoseget, olvashatosagot.
Szeirntem en mondtam konkretumokat, hogy pontosan mi az amit prolemasnak gondolok, azokat nem nagyon cafoltad.
Itt egy kodreszlet, mi az amit megertessz belole?:
generator.Errors.ToList().ForEach(mce => Console.WriteLine(“{0}: {1}”, mce.IsWarning ? “Warning” : “Error”, mce.Message));
Megerted a “logikat”, de nem tudod, hogy milyen tipusokrol van szo. En _nagyon_ hianyolom azt az informaciot, hogy lassam, hogy milyen tipusu az Errors collection. Most kepzeld el, hogy van egy fuggvenyben vagy 5-10 db ilyen kifejezes. Sokkal-sokkal tovabb tart megertni a fuggveny mukodeset igy, mintha “hagyomanyos” foreach-ek lennenek. Hasonlo okokbol foreach-be ciklusvaltozonak var-t irni tipuskent szinten bun.
Azért nem ragadtam ki konkrét példákat, és nem is válaszoltam konkrét példákkal, mert nem szerencsés…
Pont ezt írtam, hogy a LINQ 2 SQL N E M a következő generációs csoda, de még az Entity Framework sem, amire most azonnal mindent le kell cserélni…
És maga a LINQ sem olyan valamit amit orba-szájba egyfolytában használni kell(ene)…
Ellenkezőleg : ez új utakat-megoldásokat nyit meg neked, sokszor csak leírásban. sőt mindig : ugyan a LINQ foreach-ekre, for-okra, if-ekre, meg switechekre fordul le…
A fenti példában pl. kifejezés vége teljesen egyértelmű! Csak én mondjuk Action-nek, vagy DoWithAll – nak hívnám a ForEach extension methodot…
Innen már mindenkinek egyértelmű, hogy a kollekció minden elemére megcsinálom az adott hívást(lamdba kifejezés).
(Ehhez persze kell hogy értse az ember a lambdát…)
Képzelj oda még egy szelekciót, rendezést ( where, orderby), és akkor azonnal!!! Szemléletesebb mintha leírtál volna egy szelektálás majd egy rendezés algoritmust egy rakat for/if-fel… Még akkor is ha ezeket metódusban valósítod meg… mert akkor meg a kifejezésben a leírás és végrehajtás fordított sorrendben történik (balrol jobb olvasunk, belülről kifele történik a végrehajtás…)
Ergó 10-20 c# sor helyett lett 1.
Melyik az érthetőbb????
SZERINTEM a LINQ.
DE
Sokszor az ellenkezője igaz.
Tehát nem egyik vagy másik, hanem mindkettő szimbiozisban, a feladatnak megfelelően.
Továbbra is szerény véleményem szerint hibás lenne minden hasonló újdonságot enterprise fejlesztésekben megtiltani, csak azért meg gondolkodni kell néha…
Hat ha szerinted a pelda LINQ-val erthetobb, akkor mondd meg nekem, hogy milyen tipusu az mce.
Szerintem te azt hiszed, hogy nem ertem a LINQ kifejezeseket, holott leirtam konkretan, hogy az (is) a bajom vele, hogy nem latom, hogy milyen tipusu adatokon dolgozik. Oke, a compiler kitalalja (type inference), de nekem miert kell kikovetkeztetnem (faraszto, felesleges melo), ha egybol lehetne latni, mert oda lenne irva. Oke, ertem a kodot valamilyen szinten a tipus informacio nelkul is, de rogton felmerul egy kerdojel az olvasas kozben: Milyen side-effectjei lehetnek annak az egy sornak? Ezt a kerdest a tipusok ismereteben sokkal konnyebb mevalaszloni.
En teljesen tisztaban vagyok azzal, hogy lehet jol (megefelo helyen) hasznalni a C# 3.0 feature-eit, de nagyon nehez, olyan, mintha egy pisztolyt adnal egy majom kezebe. Nagy projektes kornyezetben atlag programozoid vannak, nincsen olyan, hogy mindenkit szuper programozova oktatsz a teamben. Teljesen biztos, hogy labon lovitek magatokat. Nem tudom, neked peldaul mi a velemenyed a “var a foreach-ben” kerdesrol, nem is vagyok biztos benne, hogy van kialakult, megalapozott programozoi gyakorlatod ebben a konret esetben.
Ilyenkor csak azt teheted, hogy szigoru policyket, konvenciokat allitassz fel, es folyamatosan ellenorzod a betartasukat. Extra overhead, hibaforras. Egyatlatan, az is rengeteg melo, hogy kialakitsd ezeket a konveciokat. Velemenyem szerint oszessegeben egyszeruen nem eri meg.
:)
Diagnosztizált LINQ allergia :)))
provokáció off…bocs. magas labda volt…
—-
Azzal kezdtem, hogy NEM dolgoztam über giga projekten 10-20 emberrel, így megítélni csak kívülről tudom… a véleményem ez, és lehet hogy rossz…
Sőt ellenkezőleg, én 2-4 emberrel dolgozom együtt, akik jóval átlagon felül vannak .Net-ben, és született érzékük van az ilyenekre… így nálunk ez semmiféle hátrányt nem okoz…
Ha Te úgy érzed, hogy egy olyan projektben ahol 20 indiai vendég munkás, 22 éves egyetemista kóder (nem bántásképpp!!!!) vagy akár a profik kóder önti a millió kódsort (és maximum csak használják a LINQ-t, de nem értik, vagy nem mindenki), és ez érzésed szerint inkább hátrányára mint előnyére válik a projektnek, akkor tiltsd policyvel és irtsd tűzzel vassal.
Erre én nem látok rá…
Élesen él emlékezetemben Luke Hoban(LINQ 2 Object PM-je) egyik előadása, melyben azt az utat magyarázza hogyan alakultak ki a követlemények a c# 3.0-val kapcsolatban, és ebből mi valósult meg…
Nos ebben ecseteli, hogy ezen újdonságok nagy részét maguk a fejlesztők kérték… akikre itt konkrétan utal, azok azok a nagy gyártók, ISV-k, akik Redmond-ban direkt kapcsolatban állnak az MS-sel, tehát nem a 10-20 fős fejlesztőbrigádok, hanem az 1000-2000 fősek…
Csak tudhatnak valamit ezek is nem?!?
Na elokerestem neked azt a jo kis interjut:
Ez a lenyeg:
“C# is basically silent on the checked exceptions issue. Once a better solution is known—and trust me we continue to think about it—we can go back and actually put something in place. I’m a strong believer that if you don’t have anything right to say, or anything that moves the art forward, then you’d better just be completely silent and neutral, as opposed to trying to lay out a framework.
If you ask beginning programmers to write a calendar control, they often think to themselves, “Oh, I’m going to write the world’s best calendar control! It’s going to be polymorphic with respect to the kind of calendar. It will have displayers, and mungers, and this, that, and the other.” They need to ship a calendar application in two months. They put all this infrastructure into place in the control, and then spend two days writing a crappy calendar application on top of it. They’ll think, “In the next version of the application, I’m going to do so much more.”
Once they start thinking about how they’re actually going to implement all of these other concretizations of their abstract design, however, it turns out that their design is completely wrong. And now they’ve painted themself into a corner, and they have to throw the whole thing out. I have seen that over and over. I’m a strong believer in being minimalistic. Unless you actually are going to solve the general problem, don’t try and put in place a framework for solving a specific one, because you don’t know what that framework should look like. ”
forras: http://www.artima.com/intv/handcuffs.html
Maximalisan egyetertek ezzel. Es a C# 3.0 featurejei teljesen szembe mennek ezzel az elvvel. Az egy eleve megkerdojelezheto modszer, hogy korbekerdezek nagy cegeket, hogy mit szeretnenek (akik egyebken biztosan profik a sajat know-domainjukben, de biztos lehetsz, hogy nem azok, amikor egy nyelvet kell tervezni), es belepakolnak parat beloluk.
A C# 4.0-ban is az egyetlen tisztan hasznos feture a “co” es “contra variance”. Ennek mar a 3.0-ban is benne kellett volna lennie.
Az idézettel én maximálisan egyet értek.
Akár szó szerint lefordíthatnám azt a mondatot ami arról szól hogy újra és újra beleesik az ember abba a hibába, hogy a világegyetem problémáját akarja leprogramozni, és bonyolult dolgokat gyárt, és 99%-ban újra fogja írni… nem feltétlen mert bugos, hanem mert nem azt sikerült elérnie amit akart… vagy változott közben a specifikáció.
Ezt a hibát anno én is elkövettem, és látok rá nap mint nap példát…
DE. SZERINTEM…
Nem keverendő össze a tervezés, architektúra, framework készítés, megoldás fejlesztés ill. ezek elbonyolítása azzal hogy milyen nyelvi elemeket, használ vagy nem használ, és ha igen akkor azt hogyan teszi…
Ez a kettő teljesen más absztrakciós szinten van.
Lehet jól megtervezett “frameworkot” sz*rul programozni, és fordítva… sőt bármilyen kombináció előfordulhat és elő is fordul…
Az idézet gondolatmenetet maximálisan vallom, sokszor keresnek meg valami über-elbonyolított dologgal (leprogramozták a világegyetemet), hogy miért lassú? meg hogy állandóan falakba ütköznek… és kérdik miért?!?
Azért mert azt programozták le ami építőkockákban rendelkezésre áll a .Net Framework X.X-ben Base szinten… amik ráadásul egy irányba mennek. Az ő megoldások meg szöges ellentétben áll valamely,vagy akár az egész, részével a Frameworknek.
Továbbra is igazat adok neked. Csak én azt mondom nem csak egy igazság létezik. Pl. valószínűleg azért igaza lehet azoknak is akik a C# fejlesztését viszik a vállukon. Amennyire én meg tudom ítélni, sok mindenben máshogy gondolkodnak a nagy vízen túl, mint kis hazánkban az a pár száz fejlesztő…
én nem érzem magam olyan embernek aki ezt meg tudja ítélni.biztosra.
Az út adott… nem kötelező használni még akár a 2.0-s ficsöröket sem, nem kell generikusan programozni, yield returnt használni, propertyket, delegate-eket használni…
Háááát… ha a LINQ kicsapta a biztosítékot, ha fogalmazhatok így, akkor vigyázz mikor ezt olvasod :)
http://www.fikrimvar.net/lestirelim/?p=15
Ez egy eléggé túl van a megszokottakon…
stringként bindolunk egy lamda kifejezést, ami majd menet közben lefordul :) majd kiértékelődik, végrehajtódik :))
Nem mondom hogy fejlesztő-tesztelő barát, de mindenesetre ötletes…
Jezuskrisztus… Minden architekt remalma. (Hasonloan a LINQ raytracerhez, nemtudom ismered-e, egyetlen linq kifejezes.)
Szoval ezek cool dolgok, persze, ‘amugy’ nekem is tetszik, hogy nezd, ilyet is lehet, de sose kelljen olyan kodot managelnem, ahol onjelolt kod-muveszek hasonlo modon onkifejeznek fejlesztes soran.
Az illeto matematikus. Amit csinal az comupter science. A mainstream szoftver fejlesztes nem science, hanem engineering. Oriasai a kulonbseg, es egyaltlanam nem biztos, hogy jo dolog az, ha elmossuk a hatarokat.
Szoval a Computer Science szemponjabol a C# 3.0 jo, ezt en nem kerdojelezem meg. Software Engineering szempontjabol viszont nem jo.
Sziasztok!
Én éppen túl vagyok egy enterprise-nak nevezhető projekten (10 ember, egy év), amiben kihasználtuk az említett dolgokat, és alapvetően pozitív a véleményem róluk:
1. var: Ha az ember jól nevezi el a változóit, akkor megkönnyíti az olvashatóságot.
List employees = new List();
helyett olvashatóbb a
var employees = new List();
A lényeg a változók elnevezésén van: ha abban benne van a tartalom, akkor a típus fölöslegesen növeli a zajt.
2. extension method: Megszokható és szerethető. Arra se panaszkodunk, hogy egy metódushívásból nem tudjuk megállapítani, hogy az adott osztály implementálja-e vagy valamelyik őse. A fejlesztőkörnyezet meg úgyis odavisz a definícióhoz. Ugyanígy van az extension methoddal. Az extension method önmagában nem hordoz túl nagy értéket, a lényege az, hogy lehetővé teszi a LINQ-t.
3. LINQ: Itt alapvetően a LINQ to SQL-ről van szó, gondolom, mert ott számít az, hogy nem tudjuk pontosan, hogy mikor hajtódik végre egy SQL parancs. Ez szerintem is egy létező probléma, nem csak performancia okokból. Például megnehezíti a többrétegű alkalmazások írását, mert egy felső szinten lehet hogy nem akarok vagy nem tudok egy datacontext-et fenntartani.
Mi azt a megoldást használtuk, hogy kikapcsoltuk a DeferredLoading-ot és a datacontext-et is eldobtuk lekérdezés után. Így a LINQ lekérdezések egy “disconnected” entitást adtak vissza, amin már nem lehetett újabb lekérdezéseket végrehajtani.
Nagyon sokat nyertünk a LINQ-val a refaktoráláson. Mivel a LINQ lekérdezések nem stringek, hanem kifejezések, bármilyen adatbázisváltoztatás fordítási hibát eredményezett, amit pillanatok alatt ki tudtunk igazítani.
Szerintem ezek jó feature-ök, csak gondosan kell őket használni – ugyanúgy mint minden mást amit már megszoktunk.
Kiigazítás: a generics tipusokat kihagyta az oldal a kommentemből: a fenti példakódban List helyett List<Employee> van.
KRis, meg tudod fogalmazni, hogy mi a gond a VB.NET-el a szintaxison kivul?
Írtam volna ilyet, hogy van vele bajom?!?
Már nem emléxem :)
Én annó 1 évet kódoltam vb.net-ben .Net 1.1-el.
Semmi bajom nem volt vele.
De azt tudom hogy miután átverekedtem magam a kezdeti dolgokon, akkor az az érzés alakult ki bennem hogy jobban “szeretem” a c#-t.
Ez NEM azt jelenti hogy bármi bajom van a VB-vel, mivel hogy ez egy személyes érzés :)
Mivel szerintem a világ egyértelműen c# irányba megy, ezért személy szerint úgy gondolom hogy hosszútávon biztos önsanyargatás a VB, és valamikor egyszer úgy is visszaüt, hogy nem c# guru, hanem vb guru vagy, és abban van a projekted a munkád, az életed…
Mivel hogy a legmagasabb szinten specifikálva van a .Net-ben hogy a nyelvek “egyenlőek”, ugyan azt kell tudniuk, ugyan az az IL születik, ugyan azok a tipusok, így elvileg a 2 nyelv egyenértékű.
Max a compiler biztosít pár extra lehetőséget… De ugye notepad-ban is lehet kódolni :)))))
De en nem a szubjektiv velemenyed kerdeztem a VB.NET-rol, hanem az objektiv problemakat, amik ront(hat)jak a csapat hatekonysagat. (Mert vegulis oda akarok kijutni, hogy a nyelvi konstrukcioknak igenis komoly kovetkezmenyei vannak a team teljesitmenyere.) Igaz, nem adtam meg kontextust, de altalaban a kozepes/nagy projekteket gondolom az alapkontextusnak.
A nyelvi egyenloseg csak elvi jelentosegu. A gyakorlatban sok minden fugg attol, hogy a nyelv milyen csapda lehetosegeket hagy nyitva a csapatok szamara, es melyeket nem. Es hat a VB.NET-ben vannak olyan eszkozok, amelyek rossz programozasi gyakorlatra “kesztetnek”. Ezekre lettem volna kivancsi.
Ezen a vonalon visszakapcsolodva az eredeti temahoz, a C# 3.0 uj featurejei engem a VB.NET csapdaira emlekeztetnek. Es bar ez egy szubjektiv velemeny, orulnek, ha valaki objektiven cafolna/alatamasztana.
Objektív véleményem azért nincsen, mert teljesen kikopott az info a VB.Net-ről. Egészen egyszerűen nem láttam már VB-t 5 éve.
Persze sejtésem szerint arra gondolsz, hogy a VB bizonyos mértékben bizonyos dolgokban “szabadabb” mint a c#, pontosabban más. Néha megengedőbb… Persze így több az esetleges hiba is.
Ezzel valamilyen szinten egyetértek. De.
Ezt mindenki tudja. könyvek 1000 oldalai szólnak róla. Ezek nagy része történelemi okokból van így. Felmérések szerint van vagy 60.000.000+ ember akinek valamilyen köze volt/van/lesz a VB valamely verziójához (VB 1.0 – .Net 3.5/4).
Tehát ezek a szakemberek tisztában vannak ezzekkel a dolgokkal, ennek fényében ez az emlegetett hibázási lehetőség szerintem nem számottevő.
Ha elmesélnéd nekik ezeket, szerintem nem értenék hogy miről beszélsz, mivel semmivel sem több náluk a hiba mint c# projektekben.
Messziről nézve értem én mire gondolsz… az erős specifikációk, hátárok közé szorítása a fejlesztésnek ( a lehető legtöbb lehetséges hibaforrás kizárása miatt), patternek, módszertanok szigorú alkalmazása eredményes.
De ehhez megfelelő projektméret, elszántság, pénz, oktatás és sok minden egyébb kell. és ez minimum középtávon fog megtérülni egy ISV cégnél, ahol öntik a kódot/terméket a mókusok.
Csak ismételni tudom magam, hogy én ebbe nem látok bele. Ha te úgy gondolod, mert belelátsz, hogy ebben a közegben hátráltat pl. a c# 3.0 akkor ne használd.
Privát nem mérvadó véleményem szerint többet veszítesz ezen technológiák mint lehetőségek félretevésével, mint amit az esetleges vélt vagy valós problémál okoznak/okozhatnak ezen dolgok alkalmazása.
Egészen egyszerűen azért, mert majd más megtalálja majd a módját hogy alkalmazza ezeket egy hasonló szervezetben….és ekkor máris hátrányban vagy…
Lefordítva… meg lehet találni a módját szerintem annak is hogy lambda-kat használjon az ember…
Nehéz ezt számszerűsíteni, de szerintem ezek a ficsörök(jól alkalmazva, megtanulva!!!!) gyorsítanak a fejlesztésen. Ergó neked nem 100.000 emberóra kell egy projekthez hanem csak 98.000. Mindenki happy mert prémiumot kap.
Lehetőségek:
-benne van a pakliban hogy +5000ó-t fog okozni egy bug közvetlenül e miatt… megtanulod, következőre már nem…
-nem jön elő bug… nyertél…
Miért kell streeszelni előre egy be nem következett dolgon?!?!
Persze. Értem. hogy ha a +5000 óra csap be akkor meg astalavista… szetrúgják az ember s*ggét. Erre írtam hogy fel kell mérni az eshetőségeket.És az adott szituáció szerint dönteni.
Lehet élni a lehetőséggel és kockáztatni, és lehet óvatosan haladni.
Egy életmentő orvosi műszernél természetesen ez utóbbi… Egy belső kicsi pilot projektnél ahol nem annyira éles a helyzet ott meg próbálkozni kell…
Ezt minden esetben a felelősséget minden értelemben vállaló manager/tulajdonos fogja meghozni, mikor eldönti hogy merre tovább…
Egy IT Architektnek a feladata szerintem az mindkét iránnyal tisztában legyen, és mindkét opciót objektíven mutassa be a döntés előkészítésekor…
Jajjj…. de hosszú lett….
Szerintem ugyan arról beszélünk amúgy…
Gondolom ezek szerint Te a másik oldalt képviseled, én meg eddigi rövid pályafutásom során mindig olyan cégnél dolgoztam ahol “szabad szellem” uralkodott… Sok intuitiv,egyéni megoldás, kreativitás, rapid fejlesztés, és minden ami ehhez kapcsolódik.
Ez nem rosszabb vagy jobb… más. Alma körte….
…
Nem akarom “újra kezdeni”, csak úgy látom hogy c# 4.0-ban még egy lapáttal rátettek :
http://software.intel.com/en-us/blogs/2009/03/30/the-c-programming-language-version-40/
KRis
O, hat en tudom mi lesz a 4.0-ban, korabban irtam is, hogy az egyetlen tisztan hasznos ujdonsag a co es contra variancia a genericsnel.
A MS csak lapatolja bele a C#-ba a komplexitast, aztan az ember csak gyozze kigyomlalni, es ez egyre nehezebb.
Az ugye az alapproblema, hogy az egyre tobb nyelvi feature negyzetesen novo mennyisegu osszefuggest hordozhat (hiszen barmely ket feature kozott lehet nem trivialis osszefugges, ez O(n^2)), ami gyorsan kezelhetetlenne valik.
Ez nem “oldal” kerdese, hogy ki all melyik oldalon, hanem objektiv teny.
De hogy nyissak uj frontot is :) Az utobbi idoben volt alkalmam kicsit elmelyulni az XAML-ben, es hat a Binding megoldasat, sot ugy altalaban a MarkupExtension modszert alapvetoen elhibazottnak tartom a nagyon gyengen tipusossaga miatt. A XAML-rol is ordit, hogy nincsenek kiforrva a koncepciok, es sajnos ugy tunik, hogy a MS mar annyi energiat olt bele, hogy ez a helyzet csontosodik. Kaptunk hosszutavra egy nyelvet, amelynek nemely eleme a javascriptet megszegyenitoen gyengen tipusos. Kar.
Az tény hogy az MS gőzerővel dolgozik, és előre szalad.
De amit írtál az nem igaz. A WPF, WF, SL2 minden ami a XAML-t “használja” az tipusus. Maga a .NET tipusus, erősen. Tehát a XAML, ami csak az alkalmazás leírására szolgál az nem teheti “tipustalanná” az alatta lévő technológiát.
Amire szerintem Te gondolsz az az hogy a XAML szerkesztő BUTA,BUGOS. Ezt mindenki tudja.
Az hogy csomó mindent megeszik, ami miatt tűnik annak hogy tipustalan, az nem más minthogy rengeteg Converter fut a háttérben, ill. parsolás.
És a megfelelő tipus lesz belőle.
Természetesen emiatt sok dolog fordítási időben nem derül ki, csak futási időben amikor a tényleges parsolás, konvertálás történik.
Ez nem téveszthető, tévesztendő össze a VB gyenge tipusosságával, vagy a JS-el.
Amúgy egyetértek, hogy a XAML szerkesztő, intellisense egyelőre GYENGE,hibás már-már fárasztó…
De ezt majd orvosolják, ez nem a XAML-t magát, hanem az EDITORT,eszközt minősíti.
——-
C# 4.0-t nem láttam még részletesen, csak megemlítettem hogy jönnek az új dolgok…
Én úgy látom hogy ezek a dolgok, a fentiek ellenére, produktívabbá teszik az egész feljelsztést összességében. És ma gyakorlatilag nem számít más (egy két területet leszámítva). Ha valamivel gyorsabban lehet fejleszteni, úgy hogy a végeredmény ugyan az, netalántán jobb/több, akkor nyert.
Még ha a programozóank ordo (n*n) dolgot kell is fejben tartania, úgy hogy n expnonenciálisan nő, egyre gyorsul…
Nyissunk egy új témát…
Soci? valami?
Dehogynem igazam van :)
Egy tipusrendszert legalabb harom, kvazi fuggetlen tulajdonsaggal lehet jellemezni:
– biztonsag (type safety)
– statikus-dinamikus tipusossag
– erosen tipusos – gyengen tipusos.
A .NET futtatokornyezet a typesafety-t biztostitja szamodra. A tobbi inkabb a nyelv tipusos kepessegeit jellemzi. Igy pl siman elofordulhat, hogy a C# erosen tipusos nyelv, mig a VB.NET nem, pedig ugyanabban a futtatokornyezet futnak. Ugyanakkor mindketto typesafe. (*) Igy aztan siman lehet az is, hogy az XAML mas tipus jellemzokkel bir, mint mas .NET-re epulo nyelvek. Az XAML valojaban egy furcsa (koncepciotlan?) keverket tartalmazza az erosen es gyengen tipusos featurenek.
(*) Azert a .NET futtatokornyezetnek van nem typesafe kepessegei is, ezeket tudod kihasznalni a C#-os unsafe keyworddel, vagy managed C++-ban. De ha a .NET nem tamogatna, akkor nem lehetne egy nyelv sem a tetejen nem-typesafe.
Nincs mit hozzátennem :)))
Nem kell használni :)
—
Pont annyira tipusos mint alatta a rendszer.
Hogy a designer buta az egy dolog.
Az meg hogy futnak a parsolások és a konvertálások alatta, az egy másik.
De ettől még nem lesz JS :)
KRis
“Pont annyira tipusos mint alatta a rendszer.”
Mi az, hogy “annyira tipusos”? Mondtam peldakat, hogy az erosen tipusossag kevesbe az alatta levo rendszer fuggvenye. Mondok masik peldat: a dinamikus tipusossag “emulalhato” statikusan tipusos kornyezetben egy “mindent vivo” tipus definiciojaval, ilyen volt regen a VARIANT C++-ban, hatha meg emlekszel. Szoval meg olyat is lehet, hogy egy kod reszlet egy statikusan tipusos nyelvben dinamikus, szoval ez meg megkevesbe csak az alatta levo futtatokornyezet fuggvenye. Szoval az idezett allitasod azon kivul, hogy nem is nagyon ertelmezheto, meg jo indulattal sem igaz.
“Hogy a designer buta az egy dolog.”
Ez sem mindig implementacios hianyossag. Lattal te mar valaha dinamikus nyelvhez jo intellisense-t? Egyszeruen elvileg sem lehet jo intellisense-t csinalni egy olyan nyelvhez, ahol a valtozoknak csak futas kozben van tipusa. Ez elvi korlat. Ugyanez az elvi korlat van az XAML-ben Binding “designolasa” eseteben. Egyszeruen nem all rendelkezesre a Binding Source tipus informacio, mert az csak runtime derul ki.
“Egyszeruen nem all rendelkezesre a Binding Source tipus informacio, mert az csak runtime derul ki.”
Megj.: Az egy dolog, hogy letezik az objektum, csak nem tudom a tipusat, ez az eset gyakran elofordul C#-ban is, pl. a databinding scenariok eseteben is. De a C# legalabb biztositja, hogy a databinding source valami valid .net-es objektum lesz (vagy null), viszont az XAML-es Bindingnel meg abban sem lehetsz biztos, hogy egyaltalan valami ertelmezhetot irsz-e be source-nak. Ez viszont mar tenyleg JS szintu gyengeseg.
Félreértesz…
Én NEM a bitekről beszélgetek…
nem is akarok. ezért fogalmazok pongyolán.
innen indult a beszélgetés. hogy jó ez globálisan messziről szemlélve…
Lehet hozni példákat 83-ban íródott könyvekből, amikben leírták hogy mi ennek meg annak a definíciója… Félreértés ne essék, tisztelet nekik!
C# 3.0-4.0 egy 200x-től fejlesztett nyelv, amelynek már a kezdetek kezdetén célja volt hogy ne legyen konzervativ OOP, és mindenből a legjobbat a cél érdekében. Soha nem volt cél ennek vagy annak való megfelelés. Ez a lényeg, csak előre nézni…
Biztos hogy kerül bele olyan ami nem felel meg sokféle szabványnak, tipusosságnak, meg egyebeknek.
Biztos hogy ez sok embernek nem tetszik, biztos hogy sokan gondolják úgy hogy ez hátrány mint előny, és fordítva.
————-
A XAML jelen esetben egy application leíró nyelv, amely NEM .Net nyelv a szó szoros értelmében(CLS). Így nincs is miről beszélni. Pusztán csak ezzel írjuk le a felületet, meg egy rakás másik dolgot (mert így “”jobb””-nak gondoljuk, könnyebb az életünk).
Hogy a Runtime alattunk ezt hogyan parsolja majd futás közben hogy lesz belőle IL kód .Net ojjektum, bináris kód, az egy másik történet. Ebbe bele lehet kötni. De miután megtörtént pontosan ugyan azokat az objektumokat kapjuk, ugyan azokkal a lehetőségekkel mint 1.0-2.0-3.0 esetben…
————-
Tehát visszatérve a post legelején felvetett kérdés-felelekre, nem az a kérdés hogy ez most bit szinten jó e vagy nem, én ezzel nem foglalkozom, nem is akarok.
SZERINTEM előremutató ez az egész történet, és a világ e felé tart. Aki lemarad az kimarad.
SZERINTEM nem vitatható hogy a c++ nál produktivabb az MFC, annál meg a VB6,.Net eleje.
.Net 1.1 nél meg a 2.0, 2.0-nál meg a 3.5.
Folytatható a sor.
Ha egy ugráson nem is mérhető, számottevő a különbség, attól még az hogy az ultrabutál módon tipusos, minden fordítási időben kiderül C-nél produktívabb a .Net 2.0 ablakos (Forms) alkalmazására. Talán ez nem vitatható, hanem tényleg tény.
Hasonlóan van így ez a most még utolsókat rúgó technológiákkal, még néha néha el lehet lőni őket, és lehet belőlük élni. De már nem sokáig.
Így lesz ez szépen a .Net 2.0-val is lassan. Jön az **** Bt. aki szebb, jobb, gyorsabb, olcsóbb mert ő 10 évvel aktuálisabb dolgot használ, így ő nyer. Még akkor is ha “elvi” értelemben szó szerint sz*rabb technológiát/nyelvet használ.
Igazat adok Neked bit szinten, ezt már írtam is. Pontosabban ez szubjektiv, még akkor is ha objektívnak gondolod. Objektiv egy mérce alapján amit szubjektiven gondolt ki valalki és lett belőle szabvány, könyv…
Tehát SZERINTEM jó ez így, pontosabban nekem megfelel. A világ, még ha kis hazánk le is van maradva egy picit, efelé tart.
(amit fent írtam, nem bitszinten…)
Csak egy példa: van egy-két cég, magyar, akik mostanában akarnak VB1-6-ról átállni .Net-re mert bedarálja őket a piac, már itthon is.
A Microsoft platformot akarnak választani, akkor ez van, ezt kell szeretni.
Ha nem MS akkor meg…. de most nem erről beszélünk.
Egy másik példa: dolgoztam anno egy nagy magyar multinál. Volt egy sz*r ügyviteli rendszer. mindenki tudta hogy az a user és a főnök és a tulaj is. egy nagy irodában dolgozott 30 user. néha lefagyott a rendszer, ekkor az új alkalmazottak hangosan szentségeltek, majd oda ment a főnök hozzájuk és mondta hogy tudjuk tudjuk, de minek szidni? már dolgoznak rajta, már előtted 1000-en is mondták. Majd lesz jobb… de ha meg nem akkor is: mi qva sok pénzt keresünk vele, és így te is kapsz fizetést….
Én ez bennem úgy maradt meg, hogy a világ sosem lesz tökéletes. minden változik. és ezzel kell dolgoznunk… persze nem kötelező…
—
közben megjött a postod a JS-ről….
továbbra is… az hogy mit írhatsz le XAML-ben az egy dolog, ‘azé van mert sz*r a szerkesztő…
és igen, sajna csak futási időben parzol.
De c#-ban is legalább annyiszor csak futáskor derül ki, mint fordításkor…
ha mehet akkor megy, ha nem akkor elszáll. egy az egyben úgy mint a XAML esetében.
—
Részemről befejeztem. Leírtam amit akartam :)
Én boldog vagyok így :)
KRis
En ertem, amit mondassz, de azert szerintem kozos erdekunk lenne nem visszakanyarodni a VB6-os, minden-gany-mert-felaldoztuk a-produktivitas-oltaran a-minoseget vilagohoz. A produktivitas nincs ingyen. Majd par ev mulva, amikor mar elkepeszto mennyisegu tre kod halmozodott fel, es mas dolgod sem lesz, mint az ilyen kod turasa (mert mondjuk a kedves indiai kollega minden valtozot dynamic-nak deklaralt, mert az milyen produktiv – ok ez nem volt polkorrekt, raadasul demagog is), akkor talan mas lesz kicsit a velemenyed. Most lehet, hogy boldog vagy igy. Ez a rendszer ki fogja termelni az elekepesztoen tudas igenyes ugyanakkor elkepesztoen gany melokat. Biztos jo lesz nekunk az, ha osszekeveredik a ketto?
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.
Okay.
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.
Off:
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
Hm, azt olvastam, hogy lecserelik benne a szovegszerkesztot WPF-esre. Nezted az uj WPF-es szovegszerkesztot? Mennyire fogjak vajon ruhelleni a fejlesztok? Mar elore “orulok” a sok anyazasnak, amit a MS fog a WPF-es editorert kapni. 90%, hogy elkurjak.
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.
LINQ 2 SQL:
nemregiben lattam egy kodot ahol az SQL elerest tisztan LINQval csinaltak meg.
megirtak az ingyom-bingyom LINQ lekerdezest es tisztan latszik, hogy “lefelejtettek” megnezni egy prfilerrel, hogy mit is csinal az SQL ennek hatasara.
a lattak volna atirjak SPre, mert olyan rettenet szuletett belole, hogy jajj…
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?
bocs kicsit sok lett az elgepeles, lehet, hogy ejjel 2 kor mar nem kene olvasni/irni? :)
Részben igazad van. De ezt már mi is írtuk, hogy egy béna c# programozó béna kódot fog írni…
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?!?!?
“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.”
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.
Van szerencsem jatszani a WPF-es VS2010 beta 1-el. Ahogy sejtettem, az egesz boszomnagy, es rohadt lassu. Kivancsi leszek hogyan nyomjak ezt majd le a fejlesztok torkan. Most ranezek a memoria felhaszanlasara: 333 Mb (Private Working Set), pedig csak ket dummy projekt van egy solutionben.
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.
:)
‘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.