- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Projektor topic
- Milyen CPU léghűtést vegyek?
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- A kánikula elviseléséhez hardverek is kellhetnek a napernyő mellé
- Kormányok / autós szimulátorok topicja
- HiFi műszaki szemmel - sztereó hangrendszerek
- Azonnali notebookos kérdések órája
- Kezdő fotósok digitális fényképei
- Milyen házat vegyek?
Hirdetés
-
Filléres Redmi érkezett
ma Az A3x nem kapott nagy bemutatót, egyszer csak felbukkant.
-
Read Only Memories: Neurodiver teszt
gp A 2064 folytatása négy teljes évet csúszott a legelső tervekhez képest – a jövő transzhumanista világa még mindig roppant érdekes, a történet azonban már nem robotok, hanem agybúvárok körül forog.
-
Perelnek a vallásos kripto-piramisjáték miatt
it Két kriptocéget perel New York államügyésze, mert több mint 1 milliárd dollárral károsították meg az áldozatokat.
Új hozzászólás Aktív témák
-
leslie23
tag
Sziasztok, egy félig-meddig elméleti jellegű kérdésem lenne.
Abszolút új vagyok C#-ban, éppen saját, megvalósítandó projektek után kutakodok. Ki is néztem egy lehetőséget, a munkahelyen van egy nyilvántartásra szolgáló Excel, néhány VBA-makróval. Jópár évvel ezelőtt készítették, szerintem már a koncepció is hibás volt, azóta meg rengeteg új igény is felbukkant és általában én kapom azt a hálás feladatot, hogy toldozzam-foldozzam a fájlt és a makrókat.
Arra gondoltam, hogy érdemesebb lenne áttérni egy SQLite, vagy akár Access alapú megoldásra, amihez késztítenék .Net-ben egy szimpla GUI-t.Amire viszont igény lenne, hogy mondjuk egy emelt jogosultsági szintű felhasználó, bejelentkezés után tudjon új mezőket (oszlopokat) bevinni a fő, nyilvántartott egységeket listázó táblába. Természetesen korlátozott számban és lehetőségekkel, én úgy képzelem el, hogy választhatna egy legördülőből, hogy string/int/enum/date legyen a data type, ezzel nagyjából valamennyi későbbi igény fedhető lenne.
Persze az új rekordok bevitelére is lenne egy userform, amin minden egyes mezőhöz tartozna egy control. Ha viszont az admin hozzáad egy Date típusú mezőt a táblához, akkor nekem arra lenne szükségem, hogy az új rekord bevitelére szolgáló userformon dinamikusan generáljak hozzá egy DatePickert, vagy pl. egy Enum típusú oszlopnál egy dropdown-t, a lehetséges értékekkel.
A kérdésem voltaképpen arra vonatkozna, hogy egyáltalán életképes-e egy ilyen koncepció (dinamikusan bővíthető/szűkíthető tábla) és ezt a GUI szintjén meg tudom-e oldani tisztességesen? Vagy az egész elképzelés felejtős és úgy érdemes nekiállni az ilyesminek, hogy egy átgondolt, fix, rögzített adatbázis struktúra legyen a GUI mögött?
Előre is köszönöm a válaszokat!
-
leslie23
tag
válasz
martonx
#8873
üzenetére
Köszönöm a válaszod!
Az a helyzet, hogy a NoSQL-ről jóformán semmit nem tudok, így egyelőre maradnék RDBMS-vonalon, ha másképp nem érdemes, akkor rögzített táblastruktúrával. Első körben ez megteszi, most egyelőre a C#/.NET tanulás részén szeretném, hogy maradjon a hangsúly.
Windows Forms Application vs. ASP.net szempontból miért lenne nagyobb előrelépés a webes megoldás? Nyilván böngészőben sokkal szebb felületet tudnék összerakni, de úgy sejtem, hogy te nem erre gondolsz...
-
leslie23
tag
válasz
martonx
#8882
üzenetére
Köszönöm a válaszokat!
(#8880) Keem1: rendben, ránézek!
(#8882) martonx: okés, akkor első körben marad a fix struktúra.
A telepítés dologgal kapcsolatban lehet van némi zavar nálam... Ha nem tévedek, akkor a VS-ban készített exe-ket simán tudom futtatni telepítés nélkül is. Maga az app és a db is egy hálózati meghajtón lenne, amit a felhasználók a saját irodai PC-jükön megnyitnának. A .NET valamennyi gépen telepítve van.
Vagy ez nem ilyen egyszerűen megoldható?[ Szerkesztve ]
-
leslie23
tag
Értem ám amit mondotok, nekem is szimpatikus egyébként a webes megoldás, annál is inkább, hogy frontend terepen szívesen ügyködök, legalább egy ilyen része is lenne akkor a projektnek.
Viszont! Feltételezem, hogy ehhez szervergépre lenne szükségem, amin fut az IIS és itt válik neccessé a dolog. Nagyvállalatnál dolgozom, de max. 25-30 ember használná az alkalmazást, és bizony előny, ha nem kell az IT-vel köröket futni és sírni, hogy biztosítsanak nekünk infrastruktúrát. Nincsenek a helyzet magaslatán és nem is vagyok benne biztos, hogy erre lenne lehetőség. Vannak belső webes megoldások, de azok döntően JSP alapúak.
A napi munkában használt szoftvereink szinte mint .NET-ben lettek írva, mondjuk nem tudom, hogy az egyes verziók közötti kompatibilitás az mennyire megoldott a keretrendszeren beül...
Szóval mindezek figyelembevételével tűnt előnyös megoldásnak a közös meghajtón megtalálható "portable" .exe + db fájl, de persze az is lehet, hogy rosszul gondolom és pikk-pakk el lehetne intézni szerver dolgot...[ Szerkesztve ]
-
leslie23
tag
köszönöm a válaszokat urak, jó látni a különböző álláspontokat!
sztanozs: igen, három szintű user matrixot szeretnék.
egyébként nem tudom, hogy van-e erre vonatkozó előírás, gyanítom, hogy nem igazán fejleszt bárki is a saját részlegének. teljesen megértem, hogy IT-s szemmel ez nem túl szimpatikus projekt. de valóban arról van szó, hogy egy 2500+ alkalmazottal rendelkelő cég durván 30 dolgozójának lenne szüksége egy egyéni megoldásra. szinte elképzelhetetlennek tartom, hogy erre időt és pénzt biztosítson a vállalat, így maradnak a saját kis garázsprojektek, az IT-t félig-meddig kihagyva a buliból. nyilván ezzel kapcsolatban senki nem fog a helpdesknek telefonálni. a meglévő intranetes webappok is hemzsegnek a bugoktól, szerintem ilyen minor dolgokra abszolút nincsen kapacitás, sajnos!
hogy máshol ez hogyan működik, azt nem tudom, de én csupa negatív tapasztalattal találkoztam eddig az ismerősi körben hasonló kérdések esetén.
[ Szerkesztve ]
-
leslie23
tag
válasz
joysefke
#8903
üzenetére
"Amiről beszélsz az egy extrém példa és azt feltételezi, hogy a munkafolyamatnak az adott "nem hivatalos" tool megkerülhetetlenül része lett, de szupport stb érdemben nem létezik rá. Tehát a valós munkafolyamat észrevétlenül(?) már annyira módosult, hogy a hivatalosan létező eszközökkel nem végezhető el (lol)."
ez itt a kulcskérdés, szerintem. jelenleg a saját irodai munkafolyamatainkat három fronton támadom:
1.) VSTO Add-ins: Outlookban, illetve Excelben néhány lépésből álló műveletek vannak összefűzve 1-1 custom gomb mögött a toolbaron. O365-tel tökéletesen működnek, de tegyük fel, hogy 1-2 éven belül jön egy frissítés, ami hazavágja őket és én már nem leszek itt. Egyszerűen törölni kell a bővítményeket és lehet csinálni úgy, ahogy korábban is ment, nincs szignifikáns különbség még csak időben sem, maximum egy picit bosszantóbb a feladat.
Bár az valóban gáz, amit sztanozs említett az ingyenes VS-sel kapcsolatban...
2.) AHK scriptek grafikus felülettel, exe-be fordítva, célszoftverek GUI-automatizációjának céljából. Itt is potenciális veszély, hogy a szoftver következő verziójában már eltérő lesz az ablakok vagy a menük felépítése, ergo használhatatlanná válnak a scriptek.
Ha így lesz, akkor ejteni kell az AHK-t, és manuálisan dolgozni, de minden feladat tökéletesen elvégezhető így is. Napi 5-10 perc intenzív kattintgatásról van szó, de ugyebár időveszteség nincs, hiszen az AHK sem gyorsabb, csak így nem szárad le az ember ujja a már a 15. másodpercben...
3.) VBA makrók - jelentések generálása, továbbítása Outlookon keresztül, illetve adathalmazok gyors átvizsgálása, fals adatok keresése.
Ha gikszer van, továbbra is minden elvégezhető manuálisan, a számolások és formázások, chartok beszúrása Excelben, mentés, az Outlookos e-mail megírása, a mentett fájl csatolása, e-mail küldése, korábban is így ment ez. Itt mondjuk van időveszteség, kb. 15 perc/fő, napi szinten, plusz ugyebár a hibalehetőségek száma egyértelműen magasabb manuális munka esetén.A mostani kis garázsprojekt (leltár adatbázis alapon) viszont valóban necces audit szempontból.
Mit gondoltok az Access használatáról? Azt meg tudnám oldani, hogy a mostani lapvédelmes meg hasonló borzalmakkal tuningolt ősrégi Excel doksit adattisztítás után átdobom Accessbe, ez lenne egy egytáblás adatbázis, ami csak jelszóval szerkeszthető (olvasási joga mindenkinek van jelenleg is). És akkor ezen felül építenék egy felületet, plusz egy másik adatbázist, ami tartalmazná az apphoz kapcsolódó további adatokat, amik pl. a jogosultságkezelés szempontjából fontosak. Nyilván nem szép megoldás az egy tábla redundancia szempontjából, viszont ez így egy független, bármikor elővehető nyilvántartás, aminek van egy kényelmesebb olvasási/szerkesztési módja is, a .NET alapú GUI...[ Szerkesztve ]
-
leslie23
tag
Sziasztok!
Egy egyszerű kliensen dolgozom WinFormsban, néhány ablakból fog állni az egész app. Tudom, hogy elavult, meg stb., csak nem akartam fejest ugrani a WPF-be.
A problémám, hogy a formok megjelenítésekor az adatok lekérése (tárolt eljárások) miatt 3-4 sec, mire megjelenik kattintástól számítva egy-egy form. Mit tudnátok javasolni erre?Már az is előrelépés szerintem, ha megjelenik a form, de a DataGridView helyén mondjuk egy loading spinner van, amíg az adatok és a renderelés el nem készül. Olvastam, hogy a BackgroundWorker felejtős, láttam példát async/await implementációra, de érdekelne, hogy általánosságban desktop appoknál szokás-e ezzel foglalkozni és ha igen, akkor létezik-e best practice?
-
leslie23
tag
válasz
Marky18
#9452
üzenetére
Jogos a kérdés, maga a tárolt eljárás egyszerű, az adatok mennyisége sem nagy. Viszont a DB nem localhoston van, hanem távoli gépen, amihez VPN-en keresztül csatlakozom. Gondolom ezért, de az SqlConnection.Open 1-1 másodpercre megakasztja a műveleteket, ha debuggerrel megyek végig a kódon.
A kapcsolatot minden lekérdezés előtt felépítem, de ha jól tudom, ilyenkor van connection pooling. Hogyan lehetne másképp? Gondolom nyitva nem tarthatom a SqlConnectiont.
Ami még időigényes lépésnek tűnik az egy foreach a DataGridViewColumn objecteken, közben AutoSizeMode property állítása ColumnName függvényében. Furcsa, de debug mode-ban ez is 1 másodperc mire lefut, pedig eventet nem hívok közben és 12 oszlop (és olyan 50 sor) az egész. -
leslie23
tag
Sziasztok! Loosely coupled példát próbálok összerakni, MVP pattern használatával (WinForms).
Gondban vagyok, hogy jelen scenario esetén pontosan mi lenne nálam a Model. A MainFormon rendeléseket listázok (Order class példányai), egy SubFormon pedig lehetőség lenne a MainFormon kijelölt rendelés(ek) státuszának módosítására. A MainForm implementál egy IView interface-t, amin keresztül a MainFormhoz tartozó presenterrel történik a kommunikáció. Viszont a kérdés, hogy jelen esetben mi lenne a model? Egy repo, amely rendelkezik egy List<Order> mezővel?
Illetve a SubForm esetén ugyanez a kérdés, ha kijelöl 3 rendelést a user, akkor a SubForm modelje egy 3 elemű List<Order> lesz, amit a MainFormról adok át a SubForm megnyitásakor? -
leslie23
tag
Sziasztok!
Azt hogy tudom észszerűen megcsinálni egy desktop appnál, hogy adatok frissítése alatt (gombra rányom, adatokat lekérem DB-ből és újra populálom + formázom a DataGrid-et, összesen ez kb. 2 másodperc) a UI ne legyen fagyva, vagyis a gomb vizuálisan ne legyen lenyomott állapotban, de újabb műveleteket ne tudjon kezdeményezni a felhasználó.
Ezeket egyébként értelmezni is nehéz lenne, mert bármilyen művelethez előzetesen az összes adat betöltése szükséges.
Egyelőre aszinkron futtatás és egy flag használata tűnik megoldásnak, a flag értékét pedig minden egyes user által indított esemény elején ellenőrizni kell. Viszont mivel elég sok control elem van a formon, ez kicsit körülményesnek tűnik. Van erre jobb megoldás? -
leslie23
tag
válasz
Alexios
#9522
üzenetére
Ez konkrétan WinForms, de gondolom ebből a szempontból a WPF is hasonló lehet. Az Enabled property kapcsolása amúgy jó ötlet, így megúszható lenne a bool flag ellenőrzés az eventök elején. Az egyetlen bajom, hogy így WinFormsnál két másodpercre minden control elszürkül, ami a relatíve sok színes ikon miatt egy viszonylag erős villanó effektust jelentene.
Esetleg a Click eventek lecsatolása, majd újbóli hozzáadása szerintetek járható út, vagy ez fapados megoldás lenne?[ Szerkesztve ]
-
leslie23
tag
válasz
martonx
#9524
üzenetére
Szia! Köszi, async-await lesz mindenképp. Viszont ha jól értelmezem, akkor az await ellenére másik gombra még rá tud kattintani a user, és le is fog futni mögöttes logika. Én lényegében ezt szeretném megakadályozni. Vagyis elkerülni azt, hogy ténylegesen fagyjon az UI, de nem engedni olyan műveleteket meghívni, amelyek csak úgy értelmezhetőek, ha a DataGridView már teljesen készen van.
-
leslie23
tag
válasz
pmonitor
#9526
üzenetére
Nagyon köszi nektek a segítséget, még nem volt időm foglalkozni vele.
Az asnyc-await biztos, az enabled propertyt elegendő lenne a menustripen false-ra tenni, szóval ez elegánsan hangzik.
Az egyetlen félelmem továbbra is a színes ikonok miatti 2-3 másodperces szürke/színes "villogás", ami az enabled változtatása során történik. Ki fogom próbálni, ha nagyon zavaró, akkor marad az OnClick eventek programozott hozzáadása/lecsatolása.
Köszi szépen a tippeket! -
leslie23
tag
Sziasztok!
ASP-guruk tanácsára lenne szükségem, bár inkább általános jellegű a kérdés. Egy viszonylag egyszerű webappon dolgozok (.NET6 Razor Pages és néhány controller, amiket AJAX-hívásokkal használok) és N-tier architecture-t próbálok kialakítani.
Van egy Data rétegem, amibe csak a domain model class-okat rakom, van egy DataAccess, amibe a Repository és UnitOfWork pattern dolgai és az EF Core-specifikus dolgok kerülnek, illetve van egy Presentation project, ami maga a webapp.Az első kérdésem, hogy a ViewModel-eket hogyan lenne célszerű elhelyezni? Jelenleg a Data projectben van egy ViewModels mappám, de logikailag ezeknek lehet a Presentation layerben lenne inkább a helye. A scaffolded Identity lapok tartalma alapján azt látom, hogy a MS fejlesztői a ViewModeleket magukba a RazorPage-ek PageModel-jébe rakják, minden laphoz tartozó .cshtml.cs fájlban van egy InputModel class, és ennek egy példányára alkalmazzák az adatkötést a [BindProperty] attribútummal. Ez a megoldás olyan szempontból is tetszik, hogy így a Data layerben nincs data annotation használat (Required és ErrorMessage stb.), hiszen ezek a dolgok logikailag gondolom inkább a Presentation layerhez tartoznak.
Viszont ha innen közelítem meg a dolgot, akkor minden esetben szükségem van Model - ViewModel mappingre, ami manuálisan nyilván sok-sok favágó kód írásával járna, AutoMapperről pedig azt olvasom, hogy nem igazán jó megoldás, ha oda-vissza adatátadás történik. Mi ilyenkor a bevett megoldás, vagy mi számít itt gold standardnek? Egyáltalán helyes a megközelítésem? Köszi előre is!
[ Szerkesztve ]
-
leslie23
tag
válasz
joysefke
#9708
üzenetére
Igen, az mindenképpen cél, hogy a presentation layernek ne legyen EF Core dependenciája és ahogy Alexios is írta, ha éppen arra van szükség, gond nélkül cserélhető legyen a DataAccess layer akár Dapperre, sima ADO.NET-re, bármire.
Mivel saját hobbiprojektről van szó, így erre soha nem fog sor kerülni, de most valahol pont az elmélet érdekelne, hogy hogyan lehet és kell ezt jól megcsinálni. Olvastam a hivatkozott MS-os leírást is egyébként.„Ami nekem sokkal szimpatikusabb...”
Huhh, lehet, hogy valami nagyon hasonlóról beszélünk egyébként, próbálom értelmezni. Neten található projektek alapján most úgy legoztam össze, hogy a presentation layer egyIUnitOfWorkinterfészt lát a DataAccessből, és aProgram.cs-ben bele van rakva egy példánya aUnitOfWork-nek DI konténerbe.IUnitOfWorkszintén interfészeket tartalmaz mint property-k (IPersonRepository,IProductRepository, stb.).
A generikus Repo-nak is van egy generikus interfésze (IRepository<T>), ebben nincs pl. Update metódus, csak Add, Remove, GetAll, GetFirst.IProductRepositoryörökölIRepository<Product>interfésztől, illetve tartalmazhat specifikus metódusokat, mondjuk épp egy ilyet hogy:void Update(Product product).
A konkrét implementációk pedig pl.:ProductRepository : Repository<Product>, IProductRepository,
vagyis öröklik a generikus repo metódusait, és implementálják az entitás-specifikus metódusokat, annak számít most mondjuk egy Update is.Ha jól értelmezem az általad írottakat, valami hasonlóra gondolsz, csak az interfészeket szerencsésebb lenne kiszervezni egy külön assembly-be, ami amúgy logikusan is hangzik.
Mondjuk ha jó a sejtésem, az EF Core-t teljesen nem lehet „száműzni” a presentation layerből, mert a DI miatt a kell a builder.Services.AddDbContext...Automapper témában sajnos csak másra tudok mutogatni, jómagam még nem kísérleteztem vele, így nem tudom mennyire validak az itt leírt ellenérvek...
[ Szerkesztve ]
-
leslie23
tag
válasz
joysefke
#9711
üzenetére
Többször is átolvastam, emésztem az infókat, de érteni vélem az érveidet és logikusan is hangzik az általad felvázolt koncepció, szóval nagyon köszönöm az idődet és a segítséget!
GitHubon és demo tutorialokban főleg egyszerű, néhány oldalas CRUD appokat látok mindig, szóval nehéz olyan realworld cuccost találni, ami komplex, mégis jól átgondolt, és követ valamiféle helyes gyakorlatot. Lassan, de kezd tisztulni a kép, köszi még egyszer! -
leslie23
tag
Sziasztok,
elég noob kérdés, de nem találok rá egyértelmű választ. Van az MNB-nek egy jó öreg ASMX/WSDL árfolyamok webservice-e, amit mint web reference behivatkozva szépen le lehet tömegesen lekérni árfolyamokat.
Így néz ki a folyamat most nálam: példányosítom aGetExchangeRatesRequestBodyosztályt, beállítom az objektumcurrencyNames,startDate,endDatetualjdonságainak értékét.MNBArfolyamServiceSoapClientobjektumGetExchangeRatesmetódusának az imént létrehozottGetExchangeRatesRequestBodyobjektumot megadva mint argumentum, egyGetExchangeRatesResponseBodyobjektumot kapok vissza, aminek aGetExchangeRatesResultmetódusa adja meg a response XML-t, benne az árfolyamokkal.Nekem technikai okok miatt arra lenne szükségem, hogy ezt a műveletet web reference nélkül tudjam megoldani, a kérdés, hogy ez vajon lehetséges-e? Valami olyasmire gondolok, hogy egyszerűen felépítem a request XML-t (LINQ to XML), majd egy hívás után (gondolom a GetExchangeRates endpoint lesz a kulcs) megkapom a response XML-t. Tud ilyet az ASMX?
Előre is köszönöm a segítséget!
[ Szerkesztve ]
-
leslie23
tag
válasz
martonx
#9788
üzenetére
Köszi, pont erre gondolok, csak nem tudom összehozni...
Egyszerűség kedvéért a GetInfo endpointot górcső alá véve, így néz ki a kód web reference használatával:MNBWebservice.MNBArfolyamServiceSoapClient Client = new MNBWebservice.MNBArfolyamServiceSoapClient();MNBWebservice.GetInfoRequestBody b = new MNBWebservice.GetInfoRequestBody();MNBWebservice.GetInfoRequest r = new MNBWebservice.GetInfoRequest(b);MNBWebservice.GetInfoResponseBody re = Client.GetInfo(b);és ennek kiváltását így próbálom összehozni:
string soapXML ="<soapenv:Envelope xmlns:soapenv=\"http://schemas.xmlsoap.org/soap/envelope/\" xmlns:web=\"http://www.mnb.hu/webservices/\">" +"<soapenv:Header/>" +"<soapenv:Body>" +"<web:GetInfoRequest/>" +"</soapenv:Body>" +"</soapenv:Envelope>";using (WebClient client = new WebClient()){client.Encoding = Encoding.UTF8;string uploadString = client.UploadString("http://www.mnb.hu/webservices/MNBArfolyamServiceSoap/", soapXML);XmlDocument xmlDoc = new XmlDocument();xmlDoc.LoadXml(uploadString);}Bizonyára triviális a dolog, de nem értem hogy pontosan melyik URI-t kellene céloznom...
Az endpointot? Az ASMX-et? Mindenre 404-et kapok... 
-
leslie23
tag
Köszönöm, sikerült végre! Próbáltam már az asmx-et célozni, de 404-et kaptam, mint kiderült a https miatt...
Http-vel működik pöpecül, köszönöm a segítséget mindkettőtöknek!Arra viszont nem találtam példát/leírást, hogy a web reference-es kódból hogy tudnám kinyerni az XML-eket, erre tudsz linkelni esetleg valamit? A Fiddlerrel ha jól értem nekem kellene felépítenem a request XML-t.
[ Szerkesztve ]
-
leslie23
tag
Sziasztok!
Segítséget, vagy magyarázatot szeretnék kérni tőletek a következő probléma kapcsán, StackOverflow relevánsnak tűnő kérdéseit már átnyálaztam, de nem találtam számomra választ. Van egy WinForms alkalmazás, amivel SQL queryket szeretnék végrehajtani (kb. 70-80 darabot, egyenként 5-15 másodperc az execution time) a lekérdezések eredményeit pedig Excel-állományokba menteni. Nem parallel async végrehajtás működik, viszont kicsit tempósítandó a dolgokat átírtam Parallel.Foreach segítségével, a szimultán szálakat 15 darabban maximalizálom. Az SqlConnection using blokkban van, ennek ellenére az alábbi hibaüzenetet kapom: "The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached."
Ha a connection stringbe belefoglalom a Connection Timeout = 0 paramétert, akkor megintcsak lefut szépen a cucc. Próbáltam szintén a connection stringben állítani a Max Pool Size-et de nem volt hatása. Sajnos nem értem, hogy pontosan mi történik, ha jól értem a using végén a kapcsolat zárásra kerül és bekerül a connection poolba. Viszont ezután miért történik timeout, mikor a következő szálon ismét szükség lenne a connectionre?
Illetve ha Timeout van, miért nem tud új kapcsolatot létrehozni?Köszönöm, ha valaki rá tud világítani mi itt a kulcs.
És egyből egy másik kérdésem is lenne; a Excelt az Interop liben keresztül kezelem. Neten azt találtam, hogy maga a COM Interop nem thread safe, feltételezem ez az oka annak, hogy parallel futásnál időnként COM error, application busy üzenetet kapok (5 futásból egyszer). Alternatív megoldásként felmerült, hogy a parallel végrehajtásnál csak egy DataSetben tárolnám a lekérdezések eredményeit, majd ezt követően egy külön műveletben sorosan generálnám le az Excel-riportokat. A kérdésem, hogy mennyire célszerű nagy mennyiségű adatot (pl. 80 query, egyenként 30-40 mező és 10-12 ezer rekord) memóriában tárolni míg elér a folyamat az Exceles lépésig? Vagy mi lehet itt best practice szerintetek? -
leslie23
tag
Nagyon köszi a válaszokat! És valóban, az a szál dobja az hibát, amelyiken a query több, mint 15 másodperce fut (dokumentáció írja is, hogy a default connection timeout 15 sec, command timeout pedig 30).
Ami viszont számomra nagyon furává teszi az egészet... Ha egyetlen szál fut (csak egy kiugróan hosszú queryt választok ki a 70 közül), akkor ugyanezen kóddal nem dobja el a kapcsolatot és közel 50 másodpercig nyitva van a connection és leszedi szépen az adatokat. Command timeout be van állítva 0-ra (ez eddig is be volt), de a connection timeout a default értéken (15 sec) van. Ez magyarázza, hogy az első verziónál, szekvenciális végrehajtás mellett miért nem jött elő a connection timeout hiba a néhány hosszabb querynél sem.
Viszont onnantól kezdve, hogy a parallel szálakon, szimultán futnak a query-k és explicit módon nincs meghatározva a connection timeout, rögtön ketyeg a 15 másodperc... Ennek esetleg valamilyen SQL-oldali beállítás lehet az oka? -
leslie23
tag
válasz
sztanozs
#9803
üzenetére
Köszönöm, martonx megerősített benne, hogy inkább tárolom az adatokat a memóriában, az Exceleket pedig a folyamat végén, szép sorban létrehozom. Ez gyorsan megvan, ha nem looppal, hanem tömbből egy lépésben rakom le a munkalapokra az adatokat.
Most itt csak SELECT-ekről van szó, INSERT-nél nekem is az SqlBulkCopy szokott beválni tömeges betöltésre egy tranzakcióval. Itt most parallel foreach a harmadára csökkenti a teljes futási időt.
Viszont arról nem találok semmit, hogy a connection timeouttal akkor mi is a helyzet. Kb. így néz ki a kódom, ha MaxDegreeOfParallelism = 1, akkor lefut, ha viszont beállítom mondjuk 10-re, akkor egyből eldobja a connectiont a 15 másodperc után.
await Task.Run(() =>{Parallel.ForEach<int>(Enumerable.Range(1, 10), new ParallelOptions { MaxDegreeOfParallelism = 1 }, (number) =>{using (SqlConnection conn = new SqlConnection(@"Server=.;Database=TestDB;Trusted_Connection=True;")){SqlDataAdapter adapter = new SqlDataAdapter("WAITFOR DELAY '00:00:40' SELECT 'Hello World!' AS [Data]", conn);adapter.SelectCommand.CommandTimeout = 0;DataTable dt = new DataTable();adapter.Fill(dt);Console.WriteLine(dt.Rows[0][0]);}});}); -
leslie23
tag
válasz
rgeorge
#9806
üzenetére
Köszönöm, most rákeresve látom, hogy valóban szokás usingba tenni az SqlDataAdaptert, bár például az MSDN mintakódban nincs using és explicit Dispose() sem.
Vagy másra értetted a szabályos használatot?
Mindenesetre a fenti probléma usingba fogalalva az SqlDataAdaptert is előjön.
De egyébként nem nagy ügy, semmibe nem kerül a connection stringet kiegészíteni, csak furának találom a dolgot.
joysefke: Neked is köszi, utánaolvasok a safe thread collections témának, bennem őszintén szólva fel sem merült, hogy az alap generikus gyűjtemények ne lennének alkalmasak több szál esetén. -
leslie23
tag
Szerintetek érdemes még WPF tanulásába időt és energiát tenni? Tudom, hogy a web sokkal kifizetődőbb és nekem is ez a fő csapásirány a tanulásban, viszont néha szükségem van desktop fejlesztésre és érdekel is a téma. Ilyenkor jobb híján a WinFormshoz nyúlok, de szívesen beletanulnék valamilyen XAML-alapú technológiába. Cross-platform egyelőre nem szempont, ráadásul ahogy olvasgatok a MAUI nem tűnik kiforrott cuccnak, WinUI 3 szintén. Illetve ezekhez oktató anyagokat is nehezebb találni, WPF-hez van Youtube-on néhány igényesnek tűnő kurzus, amikben fw nélkül, vanilla MVVM fejlesztést mutatnak be, érzésem szerint első körben ez lenne optimális.
Vajon WPF-es tudás mennyire könnyen forgatható át WinUI 3/MAUI-ra? -
leslie23
tag
Nem desktop fejlesztői pozi lenne a cél, inkább az, hogy ha időnként desktopra kell összeraknom valamit, akkor tudjak szofisztikáltabb, akár reszponzív UI-t is szállítani, valamint SoC-szempontból az MVVM csábító, mert WinFormsban fejlesztettem már ugyan MVP szerint, de az annyira nem volt meggyőző. A befektetett idő bizonyos szinten mindenképp "kidobott" kategória lenne, mert ahogy írtam, a tanulásban a fő csapásirány a web nálam, a piac is mindenképp erre tendál, ugye.
Maga a XAML sem kritérium, de a C#-ot szívesen megtartanám, ezért Electron és társai nem annyira vonzanak.
Esetleg Blazor Desktopot próbálgatta már valaki?
edit: most látom, hogy van már Electron.NET is, ha ezzel van valakinek tapasztalat, jöhet az is.[ Szerkesztve ]
-
leslie23
tag
MVVM kapcsán lenne egy általános kérdésem, amire eddig nem találtam igazán jó választ.
Hogyan érdemes a Model változását jelezni a ViewModel felé? Van egy ObservableCollection ami ViewModeleket tartalmaz, ez van egy DataGridre kötve. A ViewModel lényegében wrapper a Model körül, viszont van olyan dátumom amit a ViewModel formázott stringként ad vissza a Modelből. Ha egyszerre mondjuk 10 db elem (ViewModel) dátum értékét akarom módosítani, akkor három lehetőség jutott eszembe, de egyiket sem érzem túl jónak.
Most formázott stringként adom be a ViewModelnek a beállítani kívánt értéket, a setben alakítom DateTime-má, ami bekerül a mögöttes Modelbe és a setter hívja a PropertyChanged-et is. Ez a kétszeri parse miatt nem tűnik optimálisnak.
A másik opció, hogy a Modelem implementálja az INotifyPropertyChanged-et, ezt szívem szerint kerülném, nem érzem túl jó elgondolásnak, én úgy értelmezem, hogy ez kizárólag a ViewModel feladata lenne.
A harmadik, hogy a ViewModel is DateTime-ot tartalmaz és egy ValueConverter alakítja a UI-hoz az értéket a megfelelő formátumra. Érzésre talán ez a legelegánsabb, csak ha van 10 ilyen esetem (dátumformátumok, stringek, stb.) akkor kell egy rakás ValueConverter.
Mi lehetne ilyenkor best practice?
Az egyetlen félelmem továbbra is a színes ikonok miatti 2-3 másodperces szürke/színes "villogás", ami az enabled változtatása során történik. Ki fogom próbálni, ha nagyon zavaró, akkor marad az OnClick eventek programozott hozzáadása/lecsatolása.
Új hozzászólás Aktív témák
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen