Új hozzászólás Aktív témák
-
#4423
stevve
veterán
trisztan94
#4422
válasz
trisztan94
#4422
üzenetére
"Gondoltam több Controller-re osztom a különböző funkciókat, hogy átláthatóbb legyen, korábban egyben volt az egész, már a fejemet fogtam az átláthatatlanság miatt."
Ettől még lehet több controller, sőr, a SoC miatt nem csak lehet, elvárt is. Igazából nem értem teljesen, mit miért szeretnél, de itt egy jó összefoglaló a routingról:
Link -
Nagyon jó cikk, köszi.
Akkor sem látom az értelmét egy IList-re azt mondani, hogy ne a már megírt sortot használja valaki, csak mert lusta vagyok értelmes feladatot kitalálni és a legdurvább rendezés az ABC szerinti egy feladatban. Ha ennyire a matematikus gondolkodást erőltetik, akkor csavarjanak legalább rajta, csak az meg nem programozás, hanem matek.
-
Igaz, alapozás mindenképp kell, ezt aláírom, de abban is lehet logika. Például én egy kezdőnek olyan feladatot adtam, hogy tároljon memóriában mindenféle adatokat és babrálgassa őket. Érték és ref típusok, osztály, objektum, struct, tömb, lista simán belefér egy-egy ilyen feladatba, nem kell ahhoz átvágni a .NET-et.
Csak azt mondom, legyen használható, amit feladatként kiadnak. -
Én a vart olyankor használom, ha nem érdekel, mi lesz a vége például egy linq kifejezésnek. Ha egy sima IList, IDictionary, ott is látszik, hogy az mi akar lenni. Viszont saját típusoknál tényleg nem érdemes használni, ahogy mondjátok magatok is.
oO7:
szerintem olyanokat érdemes megtanítani, hogy hogy néz ki egy jó kód, hogyan gondolkodjunk egyszerűen. Gondolkodjunk objektumokban, mintákban, elvekben és lehetőleg lássunk túl a saját kis metódusunkon és ne hekkeljünk feleslegesen. A legtöbb példa, amit manapság látok olyan messze áll a valóságtól, mint Makó Jeruzsálemtől - ahogyan a fenti is. Ennek 0 a gyakorlati haszna, de gondolom, azt nem tanítják, hogy mi az a DRY, hogy csak a legalapabb dolgot mondjam. Tudom, hogy mindig belekötök az ilyen feladványokba, ha erre járok, elnézést.
Nem értek ezekkel a tanárokkal sem egyet.Egy gázszerelőnek sem adok olyan feladatot, hogy fogó nélkül szereljen csöveket, ebből nem fog tanulni. olyanból inkább, amit el tud képzelni, kötni lehet a valósághoz. Mondjuk fél év elején megmondani a srácoknak, hogy a szemeszter végére egy nyilvántartó rendszerünk lesz, amit apró építőelemekből fogunk összerakni.
-
"byte[] fileData;
var length = fileData.Length;Vegyük észre, hogy érték adás nélkül akarja használni. nekem már az csoda, hogy a fordító lefordítja.."
Nem fordítja le ha csak ennyi van. Nem a teljes kódot másolta be a kolléga valószínűleg.
rszp:
A var nem nyel el hibákat, főleg ilyet nem.
A vart kár erőltetni? Miért?trisztan94:
Hülye feladat, amiből nem tanultok meg programozni. A tanárod vagy nem dolgozott a szakmában soha vagy csak szívat titeket. -
válasz
MrSealRD
#3845
üzenetére
A lehető legkevesebb mágiával kell élni szerintem. Egyszerűség mindenek felett.
Ha van egy osztályom, amiben egy property (különben miért kellene property, ha csak arra használom, hogy belül állítgassam), ami még publikus is, akkor nem a tostronget kezdem el felülírni, hanem használom a Name property-t. Miért?- Mert így pontosan tudom, hogy a nevet kell használnom és azt is kapom.
- Debug.
- Ha más ránéz a kódra, értse, mi van ott - vagy én két hét múlva
- Maintainability, testability és még egy sor képesség. -
"Ha azt szeretnéd, hogy a consolra a felhasználó nevét írja ki, akkor overrideolnod kell a ToString metódust. Mert alapfelállásban a class neve íródik ki."
Elnézést, hogy a távolból belekotyogok, de mi a szösznek van akkor a property, ami pont a nevet használja? Miért az osztály ToString()-jét override-olod, ha magad gyártod le a kész megoldást előtte? Ennek így semmi értelme.
j0k3r!:
Ha diplomamunka, minimum említsd meg a biztonságot, mint külön concern és legalább a SOA alapjait, mert amit te szeretnél az egy SOA végső soron... illetve az volna a szép. Az, hogy ez most REST vagy SOAP, már más tészta. -
#3292
stevve
veterán
WonderCSabo
#3291
válasz
WonderCSabo
#3291
üzenetére
Nem lehet valahogy az editorban visszatenni a régi 2010-es témát? a világos téma vakít, a dark meg az editort cseszi el.
Valahogy nincs kedvem egyesével beállítani mindent. -
Nem akarok beleszólni, de: "C,C++,C# és/vagy" Nem tudjátok eldönteni, mi kell vagy ennyihez kell érteni és még máshoz is? Ha előbbi, az baj, ha utóbbi, akkor annyit fog kérni, ha lesz egyáltalán jelentkező, amennyit tanácsadók szoktak keresni. Manapság sajnos nagyon kevés a jól megfogható álláshirdetés, pedig azokra harap a nép, mert mindenki szereti tudni, mit várnak el tőle, sallangok nélkül.
Programozó és programozó között ég és föld a különbség. Célzottabban kell keresni. Én is rengeteg ajánlatot kapok fejvadász cégektől olyan hirdetésekkel, amelyekben egyáltalán szerepel a fejlesztő vagy programozó szó. Nagy hiba, mert ezekhez a fejvadászokhoz nem fogok visszamenni. Elvárom, hogy ha egy adott területen keresnek jelöltet, az arra a területre jellemző 3 betűs rövidítéseknek legalább egy részével legyenek tisztában és legalább azt tudják, ők maguk mit akarnak.
-
Köszi, azt tudom, mikor használjak generikusokat - nagyjából mindig az én esetemben
. tegnap kicsit benéztem, ezért próbálgattam is a HashSetet. Ahogy látom, ha ömlesztve van egy csomó adatom (mondjuk milliós nagyságrendben néztem) és nem érdekel a rendezhetőség, csak ki-be akarok olvasni és gyorsan elérni, akkor jó és tényleg gyors, de egyébként IList, ha rendezett kell és ha úgyis iterálni kell. Az, hogy a hash alapján gyorsabb keresni, nem is annyira lényeges, inkább az, hogyan kellenek az adatok. -
#3220
stevve
veterán
WonderCSabo
#3219
válasz
WonderCSabo
#3219
üzenetére
Ja, értem.
-
#3218
stevve
veterán
WonderCSabo
#3216
válasz
WonderCSabo
#3216
üzenetére
Ez a HashSet generikus, de a hashtábla (HashTable) más.
"Meg amúgy is ezek a kis programok csak példák, a való életben nem 10 elemű listákkal fog csak foglalkozni a tanuló."
A példa jó is volt, én nem olvastam át elég jól elsőre.
Egyébként nyilván könnyebb hash alapján elérni valamit (int) ebben igazad van.
-
#3215
stevve
veterán
WonderCSabo
#3214
válasz
WonderCSabo
#3214
üzenetére
Igen, már látom, mit néztem be.
Viszont a hashtáblák előnyét nem látom. Kb. egyszer találkoztam olyan rendszerrel, ahol ilyenekkel kellett játszani és kínszenvedés volt (.net 2-es kód). Tudsz példákat mondani a generikusok ellenében?
"Ez az amit a hashtábla konstans idő alatt tesz meg a hozzáadással, Te pedig minden egyes új szám hozzáadásánál lineáris keresést végeznél..."
És erre írtam, hogy ha nem kell milliónyi különböző érték, nem fáj.
Ez a HashSet<T> már egy viszonylag használható dolognak tűnik az eddigi megoldásokhoz képest. Lehet, hogy majd ki is próbálom jobban.
-
#3211
stevve
veterán
WonderCSabo
#3210
válasz
WonderCSabo
#3210
üzenetére
Közben rátaláltam az MSDN-en:
"A set is a collection that contains no duplicate elements, and whose elements are in no particular order."
Vagyis valahogy még azt is ki kell ötölni, hogyan kerüljük el a duplikálást, különben hibát kapsz. Nem használtam még HashSet-et csak egyszer kipróbáltam, de nem látom az előnyét sajnos. Veszek inkább egy generikus listát és abban is bármit meg tudok oldani.
Ja, most látom, hogy a duplikálás kikerülésére trükköztetek pár hsz-en keresztül.
sosem használok randomot, erzért ez nem is foglalkoztat, de akkor már inkább vizsgálnám, hogy van-e már ilyen a kollekcióban. Ha nem kell millió rekordot disctinct módon randomolni, akkor nem lesz a teljesítmény se gond -
#3209
stevve
veterán
WonderCSabo
#3202
válasz
WonderCSabo
#3202
üzenetére
A HashSet-ben nem lehet duplikált elem, ha jól tudom, ez viszont ezt nem garantálja.
Én inkább egy sima generikus listában tárolnék. -
#3178
stevve
veterán
Peter Kiss
#3177
válasz
Peter Kiss
#3177
üzenetére
Ez a DRY, való igaz.Egyébként a feladathoz: a gomboknál felesleges a mouseDown-t használni, főleg, ha utána azt mondod, hogy mindegy, melyik gombot nyomta meg a nép - akkor már inkább a click.
-
#2876
stevve
veterán
norbitális
#2875
válasz
norbitális
#2875
üzenetére
Ezt a feladatot értelmezni sem sikerült igazán...
gondolom sulis példaprogram. Viszont használhatsz nyugodtan értelmes elnevezéseket. A programozás nem a rejtjelezésről szól és egy nagyobb programnál két hét után az, hogy Tomb2dahpr vagy ahm semmit nem fog mondani. Nekem már most sem mond semmit. -
-
Á, dehogy. Ezt eleve nem túlterhelésnek hívják, másfelől nem szükséges feltalálni a spanyol viaszt. A tryparse nem egy nagy dolog, tessék használni.
A te megoldásod teljesen feleslegesen bonyolítja túl a kódot. Ha ezt megszokod, esetleg egy nagyobb projektnél átláthatatlan lesz a sok hackeléstől az egész.
-
válasz
MrSealRD
#2781
üzenetére
Én azt vallom, hogy nem a tömb a programozás alapja, mégis azzal jön minden tananyag. Mi itt az élet alapján próbálunk segíteni, ezért emlegetünk olyan rövidítéseket, kifejezéseket, amiknek haszna is van és nem csak a jobb jegy elérésében.
Azért jobb azon az úton elindulni, mert akkor utána nem kell rosszul rögzült vagy el sem mondott dolgokkal szinte újra elkezdeni előröl az egészet. Aztán ha nem érti valaki, tovább lehet kérdezni. Ha azt írjuk le, hogy ez a megoldás és kész, abból nem tanul senki és továbbra sem fogja senki érteni, hogy miért kell neki a tömbökkel szívnia. De sajnos a suliban akkor is azt fogják számon kérni, nekünk meg ettől megáll az agyunk.
Természetesen konyhanyelven elmagyarázni valamit továbbra is nyitott vagyok én is, de nem általánosságban mert abból regény lenne.
-
-
válasz
martonx
#2751
üzenetére
Miért érdekelne engem, hogy 18223 alatt vagy épp egy GuId alatt van az x. elem? Nekem nem fáj egyik sem, mert nem akarom beégetni kódba, de pl. pont egy netes projektben szebb, ha nem úgy megy a kérés, hogy userId=1.
Egyáltalán nem kell vele szopni, ezt nem is értem.Egy autoincrement intet nehezebb is mozgatni. Ha mozgatni kell vagy esetleg Oracle alá bevinni, takarítani vagy csak mondjuk a teszt adatokat kivenni, akkor lehet gondolkodni, míg egy guid az guid. Fogod és viszed, törlöd, nem lesz semmi baja. Ráadásul sokkal szebb megoldás, nem pedig "beteg kód".
Ha ORM-et használ valaki, akkor meg végképp mindegy (vagyis előnyösebb a guid).
azért az utolsó sorral elvetted a hsz-ed élét erősen.
-
válasz
MrSealRD
#2748
üzenetére
Ja, értem. Adatbázist nem érdemes bővíteni - legalábbis gondolom, nem akarsz sémákkal játszani.
Talán megfelelően egyszerű, ha létrehozol egy táblát, amiben a szavazások vannak (Id, név) és egy másikat, amiben pedig a kérdésekre adható válaszok (Id, szavazás Id, válasz). Így annyi választ tehetsz egy kérdéshez, amennyi csak kell. (Persze máshogy is megoldható)
Javaslom, hogy az id az Guid legyen, az intet nem szeretjük a való életben, csak a sulikban erőltetik.
-
válasz
MrSealRD
#2746
üzenetére
Milyen ASP.NET? 2, 3, 4? MVC?
A felhasználókezelésre az ASP-ben van megoldás, azt nem muszáj megírni. Erre még elég.
Ha ilyen igen-nem szavazás, akkor adatbázisra meg egy tábla az aktuális szavazásról, amiben a felhasználó Id-ja és a szavazat áll. Egy bool? típus a kódban. Ha null, még nem szavazott, ha meg igen, akkor az érték. Más szerintem nem is kell. A felületen a legegyszerűbb százalékot mutatni.
Ha több opció van, akkor meg egy olyan entitás, amiben minden opció benne van és rádiógomb, ahogy a fórumokon szokott lenni.
-
#2743
stevve
veterán
Peter Kiss
#2741
válasz
Peter Kiss
#2741
üzenetére
Valóban, bár nem olyan vészes. Én inkább tömöríteni szoktam, ha nem olyan műveletről van szó, ami sok erőforrást köt le. Optimálisabb a TryParse kint.
"TextBox - tb --> tbSomething"
Igen, csak akkor ismerni kell az alkalmazott szabályrendszert. Nem szeretem a hungarian notation-t.
-
#2739
stevve
veterán
Neil Watts
#2738
válasz
Neil Watts
#2738
üzenetére
Ja, értem, akkor a feladat hülyesége. Ok. szóval a karakterekkel végül is mi a gond?
-
#2737
stevve
veterán
Peter Kiss
#2736
válasz
Peter Kiss
#2736
üzenetére
Szerintem jó helyen van. Előbb úgysem használom, ott meg úgyis elszáll, ha karaktert kap.
De természetesen érdekel a véleményed, nincs kőbe vésve. -
#2735
stevve
veterán
Neil Watts
#2734
válasz
Neil Watts
#2734
üzenetére
A randomot még értem, de miért akarod a 10-et karakterként bevinni?
Az egészeknél feleslegesen megírtál egy műveletet fonákul, ami egyébként teljesen egyértelmű
"int[] egesz = new int[] { 1, 2, 3, 4, 5, 6, 7, 8 };
for (int i = 0; i < egesz.Length; i++)
{
listBox_adat.Items.Add(egesz(i));
}"helyett
for (int i = 1; i < 9; i++)
{
listBox_adat.Items.Add(i);
}bár a te számításodból a 9 továbbra is kimarad. Miért?
Amit feljebb linkeltem kód, pont azt csinálja, hogy randomol annyi számot, amennyit a taxtBoxba írtál. Ugyanez átültethető karakterre is.
-
#2733
stevve
veterán
Peter Kiss
#2731
válasz
Peter Kiss
#2731
üzenetére
Az if szerintem nem a legjobb TryParse mellé. így nincs hibakezelés.
Egy lehetséges refaktorálás: linkKérdés, hogy kell-e üríteni a listát minden gombnyomáskor. Illetve én a randomnak egy saját metódust csinálnék, úgy még szebb.
core2:
Nem igazán értem ezt a karakteres dolgot. Mit kellene ott csinálni? De amúgy a program célját se értem. Mi a feladat?Másfelől 1-2 tanács:
- alulvonás helyett inkább egybe írd a neveket és CamelCasing-et használj.
- olyan nevet ne használj, hogy "textBox1_adatbe". Ha a kontrol nevét is bele akarod írni, akkor inkább inputText vagy bevitelTextBox vagy ilyenek.
- "namespace _1_vektor" - n ilyet biztosan ne használj. Nagyon csúnya. a Namespace legyen konkrét és globális - valami jól eltalált név.
- "int[] egesz = new int[] { 1, 2, 3, 4, 5, 6, 7, 8 };" - ez felesleges, az egész számokat a rendszer ismeri és a 10 az nem két karakter, hanem egy szám. hol a 9?
- ha már nagyon a tömbök felé mész, akkor az a sok tömb kipakolható a metódusból egy-egy field-be is:
private int[] _egesz = new int[] { 1, 2, 3, 4, 5, 6, 7, 8 };, de kár vesződni vele, mert ez úgy, ahogy van felesleges. Van egy mindig 9 elemű tömböd és annak veszed a hosszát... -
#2717
stevve
veterán
Neil Watts
#2716
válasz
Neil Watts
#2716
üzenetére
"also + (also - felso)"
Nem fordítva akartad a kivonást?
-
Igen, a legnagyobb hiba, hogy az if-ek nem voltak blokkban. Egyébként ha szebben akarod csinálni, akkor switch-et használj, valamint a z óra, perc, másodperc is bőven elég egyszer, felesleges ennyi változóval operálni. az egyik intből másikba pakolást pedig szerintem töröld az emlékeidből.
Ja, és az intbe konvertálás simán el tud hasalni, ha mondjuk egy betűt írok be. Jobb megoldás az int.Parse(Console.ReadLine()); és ezt kezelni.
-
válasz
Blake1757
#2627
üzenetére
Azt gyanítom, hogy a Request.Form-ból nem talál meg valamilyen mezőt. A teljes hibaüzenet (stack) talán segíthetne. Vagy nézd meg, hogy egyáltalán adsz-e át valamit debug módban.
Az
"if (nev == null)
{%>
<%
}
else"helyett vizsgáld azt az esetet, ahol történik is valami. Ha a nev != null, akkor... így a másik ág nem is kell majd.
-
Ha eddig nem ismerted, akkor érdemes a különböző principle-ök és desig patternek nyomába eredni és mellette a .NET framework alapjaival kezdeni. Erre az MSDN például jó kezdés.
Emellett a java és a C# közötti különbségeket kell feltérképezni, amihez ez és ez is jó segítség (bár nem feltétlenül teljesek).
Ezeken felül pedig érdemes például régi java kódok C#-ra átírásával tanulgatni.
-
-
válasz
Jester01
#2515
üzenetére
Azt lehet látni, hogy érti-e vagy sem a rekurziót, de azért nem hiszem, hogy kezdő programozónak azt kellene először megtanítani, hogy nem használunk dolgokat - a sebességről nem is beszélve. Az osztályok és interfészek kizárása pedig egyenesen bűntény. arra kell először rászoktatni a népet, nehogy rosszul rögzüljön bennük. A suliban nekünk se mondtak semmit például a DRY-ról vagy a SOLID-ról és így utólag dühös is vagyok a tanárok inkompetenciája miatt.
(#2511) Lacces:
Jól látod. Egy metódusnál a hívásban szereplő típus a lényeg, ahogy a kolléga írja. Ezért is lehetséges a túlterhelés, amikor egy metódusnak több formája létezik ugyanazon néven, csak más típusokkal. Híváskor az fogja eldönteni, hogy melyik fut le, hogy milyen paraméterekkel hívod meg. Mondjuk ez így önmagában nem az öröklés témaköre. -
A neten van egy csomó C# RPN kalkulátor, azok jók példának. Ha nem is sokkal, de rövidebben is megoldható és kevesebb szívással.
A legszebb az, ha egy expression-t adsz át egy metódusnak, aztán az majd mond valamit. Azon belül meg már a switch-case és pár if megteszi. Nem rossz a megoldásod, mert biztosan működik, csak azt hittem, ilyen elvetemült tanáraid vannak.
"Semmilyen más paramétert nem kaphat a metódus, rekurzív megírás kizárva, egyéb osztályok, interfészek használata tilos. Ez a no comment kategória."
Ez az. A tanár kb. minden értelmes programozási és tanítási módszertannal szembe megy.
Mi az, hogy nincs osztály és interfész? Ez még az isten osztályok korában él? 
A refaktorálás egy olyan eljárás, amivel a kódot utólag tesszük átláthatóbbá, rendszerezettebbé, szebbé. Például kiszervezzük osztályokba, interfészekbe, ami plusz függőséget jelent az adott helyen, szegregáljuk az interfészeket, egyszerűsítünk, általánosítunk, stb. Szép terület.
-
válasz
Boolash
#2494
üzenetére
Igen, az IList és a többi "I" kollekció javasolt, viszont ebben a kódban, amit írtál, static-ként hozod létre a listát, de üresen. Jobb megoldás, ha létrehozod, majd inicializálod és utána sessionbe vele - static nélkül. Több példány kizárására a singleton design pattern kiváló. Egyszerű és gyors megoldás.
(#2500) Boolash:
Nem kell serializable sehová. Az entitás jó úgy, ahogy van. -
válasz
Boolash
#2484
üzenetére
Közben kifutottam az időből
Session szerintem is a legszebb, de mivel intranet, nyugodtan megtehető, hogy amikor kell, akkor behívsz AD-be, ez nem okozhat gondot.
Csinálsz rá egy szép entitást (akár modellt, ha MVC) és abban letárolsz mindent. Amíg a session nyitva van, addig úgyis életben van - ha csak olvasod, érdemes singleton-t csinálni belőle.
-
-
szívesen, nem kötekedni akartam, csak ezek a tömbös feladatok mindig felhúznak, mert elrugaszkodottak. Hiába tudsz tömböt kezelni, a valós életben ritkán jön elő, ha nem speckó területre megy az ember.
A példában meg leég 3 elem, összeadod, és nullázol, hogy jöhessen a köv. 3 szám, de persze kollekciókkal már mindjárt más.
-
Dehogy van harag.
Miért lenne. azt viszont nem tudtam, hogy ez sulihoz kell. Azt hittem, otthon, magadtól akarsz c#-ozni. Ha suli, akkor más. Ott sajnos kötelező ezekkel vackolni. 
martonx:
Sajnos ezen az életpálya modell és egyebek sem segítenek. Szemléletet kellene váltani - csak ezt nehéz, már csak a szabályozások miatt is. -
válasz
Jhonny06
#2402
üzenetére
Ha jól veszem ki az eddigiekből, a C-s világból tér át a kolléga C#-ra. Szerintem egy nyelvben sem az a legérdekesebb, hogy egy index milyen típusú és hogy tudok-e olyan algoritmust, ami kettőt oszt hatfelé és megszorozza x négyzetgyökével a szinuszát. Ettől már a suliban is herótom volt, mert a valós problémákhoz nincs köze és nem gondolom, hogy bármit lehet abból tanulni, ha a matekon gondolkodik az ember, nem a programon.
Sokkal érdekesebb kérdés például az, hogy mit mikor lehet példányosítani vagy az, hogy építsünk fel egy kifejezést, mint az, hogy tömbökkel szórakozzon valaki. Nem kell mindent az IntelliSense-re bízni és nem érteni, amit leírunk, mert az sem jó, de ezt nem is mondtam. Viszont egy IQueryable kezelése sokkal hasznosabb c# tudás szerintem, mint egy tömb kezelése. Én mondjuk nem sokra mennék egy olyan fejlesztővel, aki nem tud adatbázisul, de tömbzsonglőr. Persze azért tanács a tanács, mert nem muszáj megfogadni. Ez nem baj.
"Vagy azt mondják, hogy VS meg IntelliSense nélkül jegyzettömbben írj meg valamit.."
Szerencsére ez sem gyakori valós probléma.
Mindenki túlságosan egyszerűnek látja a C#-ot, pedig nem az. Nem a túlbonyolítástól lesz valami jó.martonx:
Nem vesztettem el a türelmem, csak ennek kevés értelmét látom. Én állásinterjún a gyakorlat híve vagyok, nem a szívózásé. -
Nem bántás, de miért ilyen hülyeségekkel foglalkozol, mint ez és a buborék? Nem kioktatásnak szánom, csak leírok pár dolgot tanácsként. Miért nem életszagú példákkal dolgozol? Írj mondjuk valamilyen katalógust magadnak. Abban minden megvan, ami kellhet az alapokhoz (adatbázis, felület, backend). Kérdés, hogy mi a célod?
Másik tanácsom: dobj ki minden eddigi könyvet és linket (ahonnan ez van, onnan több példát ne vegyél, mert szerintem elavult) - és főleg C tudást, mert itt csak tömbökkel operálsz, pedig ezer éve vannak kollekciók és mindenhol azt használják már, hacsak nem valami hardver közeli dolgot (driver-t) vagy ilyesmit akarsz írni. Olvasgass az elnevezésekről és használd a ReSharper nevű igen hasznos progit a Visual Studio-ban.
A lelkesedés hasznos, de ne pazarold olyanokra, hogy milyen típusú egy tömb indexe - ez azért a nevéből is adódik. Kész, lépj tovább. Ha valaminek a valódi, lefordított kódja érdekel, akkor használj Reflectort. Garantáltan meglepődsz majd.
-
#2379
stevve
veterán
WonderCSabo
#2378
válasz
WonderCSabo
#2378
üzenetére
Ha csak a miértek érdekli, mert rájött, akkor jó.
-
-
-
A statikus osztályt nem kell létrehozni, elég csak hivatkozni rá, mert egy példányban létezik.
egyébként egy osztály egy példányban való létezése például hasznos, ha mondjuk egy konfig állományt olvasol be és dolgozol fel. Ilyenkor csak egyszer teszed meg és kizárhatod, hogy újra létrejöjjön. Tipikusan az erőforrás kezelő logikát szokták ilyen osztályokban tárolni.
-
1. Nem tudom, mit szeretnél pontosan, de ha csak 1 példányt akarsz, akkor erre van egy design pattern, a neve: Singleton
Amúgy igen, abstract, static vagy sealed (mondjuk ez csak származtatásra érvényes) és nem lehet példányosítani.
A példány instance angolul.
3. Nagyjából jó, talán kicsit túlbonyolítottad, azért nem fogadták el. Az érték szerinti átadásnál magát az értéket adod át, mindegy, hogy az hol van tárolva. Ha hivatkozol rá, magára az értékre hivatkozol, míg referenciánál egy már lefoglalt memóriaterületre (ref esetén az érték szerinti is átadható így) - de nem adod át a címet.
Ebben az esetben egy új példányt kell létrehoznod, ha használni akarod, erre való a new szó. Ilyenkor bármelyik példány módosít, mindenki a módosítottat látja majd.
-
Lejárt az idő: de az is megoldás lehet, ha külön <form> közé kerül a gomb. Vagy egy kis popup ablakkal csinálod meg, hogy másik HTTP Handlert használjon.
A Response.End() már csak azért sem ideális, mert például a Response.Redirect már eleve lefuttatja és ha azzal használod, meg sem hívódik, mert már egy End() befejezte az oldal futtatását.
-
válasz
martonx
#2324
üzenetére
Nem elég jó indok, az Express is elég a legtöbb dologra. Ha meg egy cég .NET vonalon mozog, érdemes MS partnerként tevékenykedni (akár silver, akár gold). Ez még nem indok a 2.0-nál leragadásra, csak a vezetők ezek szerint nem értik meg, hogy nekik is jobb, ha fejlődnek a programozók.
-
válasz
ArchElf
#2322
üzenetére
Bármit lehet frissíteni. A régi 2-es dolgokat nem bántja, ha kerül bele 3.0. IIS-nek nem fáj, más meg nem reklamál érte - hacsak az ügyfélnél nincs olyan policy, hogy .NET 2.0 fölötti verzió nem telepíthető, de ez meg maradiság.
Én is találkoztam olyan projekttel nem rég, ahol kerek-perec ki lett mondva, hogy csak 2.0 lehet a kódban, de indokolni nem tudták. Talán csak ahhoz értettek.Manapság azért már illik a 2.0-t elhagyni szerintem.
-
-
Lehet, hogy már nem vagyok teljesen alkalmas ma programozásra, de egy apró code behind:
Ha kivettél egyet, akkor is be tudod állítani, hogy mi legyen kiválasztva:
this.comboBox1.SelectedIndex = 1;
Vagy amelyik indexet éppen akarod. Ezt a törlés/hozzáadásnál meg tudod tenni.
Ha nem jó vagy nem értettem meg a kérdést, akkor bocs, totál kivagyok mára.
-
"Engem hozzászoktattak, hogy egyszerű dolgok nem léteznek"
Engem is, főleg a vízesés modellben, de az agilitás és az általánosságra törekvés segít felejteni.
Ma már mindenben az egyszerűséget keresem - már amiben lehet.Sk8erPeter:
"Valahogy nálam eleve nagyon komoly ellenérzést vált ki, ha egy oldal nem hajlandó valamilyen beépülő nélkül működni, tehát a felhasználó rá van kényszerítve, hogy igenis telepítse azt a szaros plugint, ha tényleg meg akarja nézni az oldalt."Ezzel én is így vagyok. Manapság a cross platform dolgok elég elterjedtek ahhoz, hogy kiváltsák a legtöbb kötött beépülőt. Persze mindig ámulok a profi flash-es oldalakon is.
-
Esetleg az EF mellett vagy helyett az NHibernate is érdekes lehet. Én azt használom és kiváló.
Akkor az az oldal elég rossz lehet. Nekem ugyan a form bejött, de nem töltöttem ki. Egyelőre nem érdekel a dolog. Ha nagyon weblapot akarok csinálni, akkor inkább DotNetNuke vagy saját MVC és valahol host.
j0k3r!:
A LinQ-s könyvet - meg még egy rakás anyagot mindentől függetlenül is érdemes elolvasni, mert nem csak adatbázisra jó. -
válasz
martonx
#2214
üzenetére
A linq-s részhez nem tettem hozzá vagy vettem el belőle, a kolléga ezt akarta. Közben privátban ment még pár kör levelezés. Én csak abban kerestem az egyszerűséget, hogy entitásokat kezelni egy rendszerben egyszerűbb, ha azok maguk alkotnak egy objektumot. Így nem kell külön alkatrészenként hurcolni őket.
public class Dokumentumok
{
public int Id {get; set;}
public string Name {get; set;}
...
}Leginkább ebben segítettem a fenti feladatban.
ha meg NHibernate is bejön a képbe, virtual minden és már lehet is mappelni.
-
válasz
Boolash
#2209
üzenetére
Nem így értem az entitást.
Az entitás tartalmazza a nevet és minden más adatot. Van egy stringed, ami alapján te kikeresed SP-ból ami kell és egy dokumentumtár típusú listába teszed, ha megfelel a feltételnek.
Innentől kiléphetsz a foreach-ből bátran, mert a dokumentumtár lista már ott van, abból azt veszel ki, ami kell. Listán is lehet szűrést alkalmazni.
Elnézést, ha túl általános, de nincs konkrét kód, csak a fenti részlet, amin szemléletesebb volna.
-
válasz
Boolash
#2207
üzenetére
Értem. Akkor talán a legegyszerűbb megoldás, ha készítesz egy entitást (sima class library), ami reperzentálja a dokumentumtárakat és azt mondod a kódban, hogy a foreach, ami mindegyiken végigmegy, egy olyan listába tegye be az aktuálisat, aminek a típusa ez az entitás. Felesleges az iterációban az a linqs rész.
Jobb kollekciókkal dolgozni, mint egyes elemeiket kirángatni és azt hurcolni.
Ez megintcsak felesleges a foreach-be:
"EntityList<Item> test = cedc.GetList<Item>(gruser.LoginName);"
Mondjuk nem tudom, ennek mi a célja pontosan, de a fentiek fényében akkor, ha van egy olyan listád, amiben minden dokumentumtár benne van, abból könnyebb válogatni
-
válasz
Boolash
#2204
üzenetére
Ha a foreach-en belül adsz a gridhez forrást, minden körben változni fog a grid forrása. szerintem te nem ezt akarod...
Nem értem a lényegét a műveletnek.
Van egy user, amit a gr.Users ad, majd kiolvasod egy listába a SP felhasználóit, majd egy linq lekérdezéssel egy entitás jön létre, majd ezt szeretnéd egy gridre felpakolni? Ez így elég zavaros. Mi a végső cél? Minden SP user kiíratása?
-
válasz
martonx
#2131
üzenetére
A LightSwitch együtt tud működni az EF-kel, úgyhogy nem itt lesz a kutya elásva. Milyen verziós EF-et használsz? Volt régebben valami bug a LS-ben, hogy nem lehetett System vagy User táblaneveket használni, bár ez tényleg régen volt. Nem lehet, hogy abban a lekérdezésben van valami gond?
-
#2128
stevve
veterán
Sk8erPeter
#2126
válasz
Sk8erPeter
#2126
üzenetére
-
#2121
stevve
veterán
Sk8erPeter
#2119
válasz
Sk8erPeter
#2119
üzenetére
Csak egy pár mondat még az időben diplomázáshoz: Van egy guru ismerősöm, aki egy tantárgy miatt majdnem ott is hagyta a sulit, mégis vannak területek, ahol alig ismerek nála jobb szakembert. Sajnos ma az iskolák jó részében azt tanítják, amire van tanár és nem azt, amit kellene célirányosan. És óriási különbségek vannak levelező és nappali, idősebb és fiatalabb diákok között - mármint értékelésben.
-
Ezért nem is nagyon használom. Inkább akkor használom simán javascriptből.
<script type="text/javascript" src="http://maps.google.com/maps/api/js?sensor=false"></script>Például hőtérképhez:
"<%= UrlFactory.CreateUrl("Home.aspx/HeatmapTile", new { zoom="\"+zoom+\"", x="\"+ coord.x + \"", y="\"+coord.y+\"", client="google", type = ViewData["type"]}) %>";Kicsit talán bonyolultabbnak tűnik, de legalább jól megy.
-
-
-
A programozásban tipikusan állandó a tanulási kényszer, de azért az borzasztó, hogy egyetemen még Linq sincs és SqlCommandokkal dobálóznak... (.NET 2 szinten max.) ez nem gondolkodás kérdése, mert ebből értelmes gondolkodás nem lesz. Így azt sem tudja meg a tanuló, mi az a perzisztáló réteg. A vicc az egészben, hogy a tárgy meg korszerű technikák néven fut.
A másik meg a GOF és a többi pattern. Miért az a cél, hogy fejből nyomják év végén az UML-t egy-egy patternhez ahelyett, hogy az obsolate-ek helyett megmutatnák, mit érdemes használni és mondjuk mindre gyakorlati példát is vennének (nem csak olyat, hogy az állatok esznek, meg hasonlók).Az oktatás színvonala a mostani döntéshozókon múlik, ergo azokon, akik összeállítják a tantervet. Ha ezek gyepesek, akkor a diák is az lesz, ha magától nem fedez fel mindent. Ez így nem oktatás szerintem. Az oktatás célja a tudás átadása (és a fejlődésre sarkalás), nem a berögződéseké.
-
válasz
Lortech
#1703
üzenetére
"Előszöris szerintem nem kéne var-t használnod ezen a szinten és konkrétan erre a feladatra."
Miért ne? Mindenhol használható. Szerintem érdemes hamar megszokni - csak persze meg is kell érteni, ezért kell utánaolvasni.
A hiba pontosan az, amit írsz, hogy amikor kiírunk, akkor WriteLine, amikor beolvasunk, akkor ReadLine kell a ReadKey pedig szolgáljon csak a program megállítására, ne legyen más funkciója.
Értelme volna mórickázni, de mégsem, mert a példa nem alkalmas semmire. Az alapoktól kezdeni annyit tesz, hogy megérteni az osztályokat, interfészeket, a C# beépített dolgait, hívásait. Példának pedig olyat érdemes nézni, kitalálni, aminek haszna is van. Mondjuk egy számológép. Kicsi, könnyű, nagyon alap.
ArchElf:
Sajnos egyelőre passzolok, ilyeneket mostanában nem csináltam... de megnézem, hátha akad valami régebbről. -
válasz
RedSign
#1697
üzenetére
pontosan, egy int nem kaphat üres string értéket, ezen azonnal elhasal a fordító. Egyébként az üres string elegánsabb módja a String.Empty;
De ha már nagyon C# 3.0 (vagy felette) az induló verzió, akkor lehet használni type inference-t is, vagyis egy olyan módszert, amivel nem kell a kód írásakor a típusokkal foglalkoznod. Ez bevett dolog az iskolapadon kívül (bár remélem, legalább ilyen alap dolgokat tanítanak) és már az alapozástól alkalmazható.
Például:
string s = String.Empty;
helyett használható simán
var s = String.Empty;
Persze ez egy nagyon egyszerű példa, de nagyon sok esetben igen hasznos dolog. A típusosság megmarad és majd a fordító kitalálja, hogy milyen típusnak is kell ott állnia.
Vannak azért megkötések is. Csak lokális változóknál használható és például lambda kifejezés esetén sem alkalmazható implicit módon.
-
#1692
stevve
veterán
Neil Watts
#1690
válasz
Neil Watts
#1690
üzenetére
Igen, az irány már megvan, csupán pár apróság:
string s = "";
Ez esetben nem feltétlenül kell rögtön értéket is adni a változónak, elég, ha csak létrehozod. Majd később adsz neki értéket úgyis.Console.ReadLine("");
Ez nem nagyon szokás. Helyette inkább
Console.ReadKey();
Nem értek ezekkel a tanárokkal sem egyet.
A vart kár erőltetni? Miért?
Valahogy nincs kedvem egyesével beállítani mindent.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- PR-Telecom
- Melyik tápegységet vegyem?
- A fociról könnyedén, egy baráti társaságban
- Könyvajánló
- Milyen autót vegyek?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Donald Trump azt mondja, hogy megtalálta a TikTok vevőjét
- Kerékpársportok
- Medence topik
- Nvidia GPU-k jövője - amit tudni vélünk
- További aktív témák...
- Eladó MSI B650 GAMING PLUS WIFI Alaplap
- Eladó PNY GeForce RTX 4070 Ti SUPER 16GB videokártya
- Bomba ár! Asus Slate EP121 Tablet - Intel Core i5 I 4GB I 64GB SSD I 12" Touch I Cam I W10 I Gari!
- Bomba ár! HP EliteBook 2570P - i5-3GEN I 4GB I 320GB I DVD I 12,5" HD I W10 I Garancia!
- Bomba ár! HP EliteBook 2560P - i5-2GEN I 4GB I 320GB I 12,5" HD I W10 I Garancia!
- iKing.Hu - Apple iPhone 13 Pro Max - Graphite - Használt, újszerű
- LG 65C4 - 65" OLED evo - 4K 144Hz - 0.1ms - NVIDIA G-Sync - FreeSync - HDMI 2.1 - 1000 Nits
- Bomba ár! HP EliteBook 2570P - i5-3GEN I 4GB I 320GB I DVD I 12,5" HD I W10 I Garancia!
- AKCIÓ! Apple Macbook Pro 15" 2018 i9 9850HK 32GB 500GB 560X 4GB garanciával hibátlan működéssel
- Nike Airmax 720 43-as sneaker eladó
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged