VS2013, EF, MSSQL, W8.1 vegyeske

Ünnepek alatt elkezdtem magamnak tákolni egy kisebb programocskát, mellékes célból azért is, hogy megnézzek néhány olyan dolgot, amit eddig nem vagy csak felületesen. Ezekről egy rövidke összefoglaló. Van itt pro/kontra vegyesen.

VS2013

A pluginekkel együtt jól bejáratott VS2010-em után elég ambivalens vagyok még mindig az új VS-ekkel, de ettől már legalább nem hányom el magam. Megjegyzem, VS2012-re kb. épp, hogy ránéztem, éles projektnél maradtam .NET4/VS2010-nél, szóval lehet, hogy van olyan újdonság, ami már nem annyira új, csak nekem.

- XAML editorban az XML tagek párját átírja, ha valamit átírunk. Már csak azt nem értem, hogy sima XML esetén miért nem teszi. Ez is olyan félmunka, mint a C# propetyhalom-xml másolás :)
- CTRL+vessző -vel előjövő kereső jó, főleg, hogy keres már fájlra is (ha jól emlékszem a VS2010 idevágó funkciója ezt nem tette, igaz ott legtöbbször a Quick Open file nevű plugin funkcióját használtam).
- Az F12 mellé (Go to definition) bejött az ALT+F12-re előjövő Peek Definition. Nagyszerű újítás. (Egy kis lebegő ablakban nyitja meg a kérdéses kódrészletet).
- Scrollbarra ki lehet rakni a kód miniatúráját, ez egyeseknek hasznos lehet.
- Ugyan minden panelnek, dokumentumnak van ikonja, de csak akkor látszik, ha nagyon picire össze vannak nyomva a fülek. Jó lenne, ha ezek mindig látszódnának. Akármit is szívtak az MS-nél az UI designerek, a kis, színes ikonokra jobban ráállt a szem, mint a sima szövegre, amit muszáj mindig elolvasni.
- Git úgy néz ki végleg betette a lábát az MS-nél.

EntityFramework
- Az ORM-ről, általánosságban már írtam, hogy nem tartom egy jó ötletnek. Hát, most is elég ambivalens érzéseim vannak a technológiával...
- Maga a code first megközelítést, annak módját meglehetősen jól kitalálta az MS, használata tényleg egyszerű tud lenni.
- Teljesítmény oldalról viszont szörnyűbb, mint számítottam. Maga az adatimportnál nem nagyon csináltam benchmarkot, de az AutoDetectChangesEnabled = false nélkül brutál lassú.
- Egy nagyobbacska 15k elemes lekérdezésnél, ami kb. 4-5 táblát joinol össze, jó 10 mp volt az adatokat kigyűjteni. Ugyanez SSMS-ben kb. 1-2 mp alatt futott le, átírva ADO.DB-re (plusz néhány saját reflectionos extension methodra, ami az lapátolást elvégezte helyettem) kódban 1.6-1,7 sec körül mozgott. Annyira nem biztató, bár tény, hogy azért általában nem ekkora listákat kérdezget le az ember.
- Szóval összességében nem rossz az EF, de az látszik, hogy a legnyerőbb itt az EF+ADO.NET kombinálása lesz.

MSSQL/LocalDB: naaaaagy jóság. (Gyakorlatilag egy MSSQL Express Edition ugyanazokkal a korlátozásokkal - 10G adat, Single core, fene se emlékszik mennyi RAM - viszont nem serviceként fut, hanem simán user processként viszonylag vállalható mennyiségű programkód felhányása után. Maguk az adatfájlok a %USER%\AppData alá kerül (pl. master, tempdb, stb.), illetve a %USER% alá (általunk létrehozott db-k) - vagy ahova akarjuk. Csatlakozni a "(localdb)\v12.0;Integrated Security=true" connection stringgel lehet, a futó user nevében. Megy Sql Server Management Studioból is, mindenhonnan, mint egy rendes SQL Server.

Ha nem használja valaki 10 percig, leáll magától. Egyrészt jó fejlesztésre, másrészt jó lehet olyan DB-k kiváltására, ami egy SQLite kevés (na meg az MSSQL Compact Edition is nyugdíjazásra kerül elvileg), viszont mégse akar az ember folyton egy SQL Servert futtatni. Plusz, ugye DB továbbvihető serviceként futó Express ill. normál verzió alá ill. vissza.

Windows 8.1
- Eddig nem tűnt fel, de most komolyan nem lehet a disk managementben úgy shrinkelni egy volume-t, hogy ne a végét, hanem az elejét tolja odébb, vagy én néztem be valamit nagyon?
- Újrahúztam 7-8 éves HDD-re 300G-s HDD-re a W8.1-et, mert egyszerűbb volt így megszabadulni a telepített cuccoktól (pl. VS2013 Expressek) plusz a kb. 13 éves Maxtor D740x sebessége, amire kényszerűségből kellett feltelepítenem, fogalmazzunk úgy, hogy khm. szar volt. Kb. olyan érzés, mint HDD-ről SSD-re váltani. Így már nagyjából használható sebessége van ennek a gépnek. (Régi gépem alkatrészei, szüleimnél összeraktam belőle egyet, mert annyira azért nem régi, de eladni meg már nem éri meg.).
- Mivel MS accounttal használom ezt a W8.1-et, egész sok beállítást átvett, bár nem mindent jól.
- Ami viszont érthetetlen, hogy miért erőlteti az MS féle ATI drivert, mikor felraktam a rendes ATI-st. Oké, 2013 januári az utolsó, de az viszont működik, szemben az MS félével, ami viszont desktopon kívül sokra nem jó. Pedig Win7-nél ez már egész jól működött.
- Viszont ha a fentibe nem futottam volna bele, valószínűleg soha az életben nem látom azt a vicces dolgot, hogy a manuális driver keresgélőnél valószínűleg a Windows 95 óta változatlan ablak van, változatlanul A:\ -el indítva :)
- Van egy halom kis hasznos context menu mindenfeké a W7-hez képest. (Pl. a Win gombra kattintva el lehet érni egyből a főbb rendszerbirizgáló dolgokat).

Hozzászólások

> Szóval összességében nem rossz az EF, de az látszik, hogy a legnyerőbb itt az EF+ADO.NET kombinálása lesz.

+1

Én általában úgy szoktam használni, hogy a legalapvetőbb query-k mehetnek pure EF-fel, egyébként pedig az EF faszán be tud küldeni közvetlen SQL parancsot a DB-nek, majd az inputot rámappeli objektumokra, ami viszont fasza

Már a 4es verzió óta használok entity frameworköt, de még nem nagyon találkoztam olyan esettel, amikor a közvetlen SQL utasítás annyival gyorsabb a jól összerakott linq vagy fluent utasításnál, hogy megérje eldobni miatta a refaktorálás támogatását (ugye ha stringben van az SQL lekérdezés akkor db oszlop vagy c# property átnevezéskor nincs fordítás idejü ellenörzés).

"- Eddig nem tűnt fel, de most komolyan nem lehet a disk managementben úgy shrinkelni egy volume-t, hogy ne a végét, hanem az elejét tolja odébb, vagy én néztem be valamit nagyon?"

Tenyleg nem lehet, es a legtobb alapszintu cucc sem tamgogatja a dolgot, ugyanis ehhez viszonylag baromi sok adatot kellene mozgatni. A veget ugye egyszeru levagni, ha nincs ott semmi, nyissz, ha van, akkor defrag + nyissz. Az elejevel mar sokkal tobb a gond, ugyanis 99.5%, hogy ott tulekszik az adatok donto tobbsege, ami egy tobbszazgigas particio eseten annyira nem vicces. Mivel a diskpart/diskmgmt.msc-t nem profi particiomenedzsernek szantak (arra van kismillio progi), igy csak a technikailag konnyebben kivitelezheto megoldast implementaltak.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Ez ott sántít, hogy az NTFS (szerencsére) nem a fogyi FAT32 módjára a lemez elejéről kezd el írni, így az adatlapátolás sehogyan sem megúszható. (Meg egyébként is, hol nem szarom le, ha kell, tegye át.)

Kicsit jobban belegondolva valószínűleg inkább az MFT lesz az oka annak, amiért nem lehet az elejét csak úgy lecsípni. Ha jól tudom két MFT van, egy a kötet elején, másik a közepén, ráadásul ezek nem mozgathatóak. (Emiatt nem lehet a felénél jobban összehúzni egy kötetet sem).

De majd valami Windows huszár kijavít, ha tévednék, most nemigazán érek rá utánanézni.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Az MFT tudtommal nem a kotet legelejen (tehat a nullas cilinderen) kezdodik, hanem joval kesobb, emiatt meg siman lehetne az elejet mozgatni (egy bizonyos pontig, persze). XP alatt meg a defragban latszott is, hogy kb. hol helyezkedik el ez a mozdithatatlan terulet...

No persze, azota verziot valtott az NTFS, azt nem tudom, hogy most hol van, a 7-esben mar nincs XP-szeru defrag GUI.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Erre a feladatra nem nagyon hasznalok 3rdparty cuccokat, mert parszor mar megegettem magam, es beleuntam a keresgelesbe. A beepitett elvegzi, amit kell, a tobbi meg annyira nem izgat, hogy orakat szanjak ra.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant:


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()