- Computex 2024: a Ducky klaviatúrái sem restek felülni az analóg vonatra
- Milyen cserélhető objektíves gépet?
- Szünetmentes tápegységek (UPS)
- Hobby elektronika
- TCL LCD és LED TV-k
- Computex 2024: asgardi ASUS ROG UPS játékosoknak
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Apple notebookok
- Androidos fejegységek
- AMD Navi Radeon™ RX 6xxx sorozat
Hirdetés
-
Filléres Redmi érkezett
ma Az A3x nem kapott nagy bemutatót, egyszer csak felbukkant.
-
Computex 2024: szimpatikus Montech billentyűzetek a porondon
ph A vállalat egy olcsóbb fajta, két színben választható, vezetékmentes modellel és két érdekesen festő koncepcióval jelentkezett.
-
Frissítve! Xbox Games Showcase 2024 - Az összes bejelentés egy helyen!
gp A műsor kora este kezdődik, utána az összes trailert összegyűjtjük egy helyre.
Új hozzászólás Aktív témák
-
Keem1
addikt
válasz leslie23 #8872 üzenetére
Az SQLite jó, könnyen kezelhető, könnyen elsajátítható, baromi gyors és könnyen egy akár meglévő programhoz is hozzákapcsolható. Én sokat használom, főleg olyan esetben, amikor sok és/vagy különböző módon elért/lekérdezett és/vagy gyorsan több adatot kezelő applikációról van szó.
Fontos! Az SQLite nem többfelhasználós. 1 app = 1 db (nyilván ez áthidalható, de akkor sem baba)! Ha ez nem hátrány, használd nyugodtan, mert szeretnivaló DBMS.[ Szerkesztve ]
-
-
martonx
veterán
válasz leslie23 #8887 üzenetére
Igaziból addig nem érzed a fájó különbséget, amíg többször bele nem futsz abba, hogy a telepített .net egyáltalán nem evidencia (vagy elég ha csak verziók térnek el), vagy ugyanígy kézzel frissítgetni a programodat a gépeken se feltétlenül triviális (egyik kolléga elvitte a notebookját, mire visszajön, meg már ki emlékszik rá) stb...
Nem véletlenül ment el a világ a web / mobil appok irányába a klasszikus telepítgetős programok helyett.Én kérek elnézést!
-
sztanozs
veterán
válasz leslie23 #8890 üzenetére
Bírom az olyan "nagyvállalatokat", ahol semmilyen architekturális előírás nincs, hogy miként és milyen környezetben kell új alkalmazásokat fejleszteni... Jogosultságkezelés legalább lesz a programban?
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
sztanozs
veterán
válasz leslie23 #8899 üzenetére
Ez a hozzáállás egész jó addig, míg be nem kopogtat az audit (vagy amíg el nem megy a "jóképességű" fejlesztő és a kollégák support nélkül maradnak).
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
Marky18
aktív tag
válasz leslie23 #9451 üzenetére
Az async-await pattern minden GUI-s alkalmazashoz ajanlatos.
En ott kezdenem a kutakodast, hogy miert tart a DB-tol a Viewig 3-4 masodpercig az adatbetoltes? Tarolt eljarasokkal szamolod on-the-fly a betoltendo adatot? Nem lenne egyszerubb ezt DB oldalon letarolni es csak egy jol iranyzott SELECT-el lekerdezni? Mindenkeppen user interakciora kell betoltened az adatot? A lekerdezes elott epited fel a DB connectiont vagy mar elore felepited?
Itt a bottleneck a DB query lesz szerintem, ha azt kikuszobolod es hasznalod az async-await patternt, akkor nem fog varakozni a main thread es a betoltes sem fog masodpercekig tartani. -
Alexios
veterán
válasz leslie23 #9521 üzenetére
Milyen desktop alkalmazás? De igazából jó úton jársz, WPF esetében pl. csinálhatsz valami bool propertyt ami ha kattintható akkor true, amúgy false, és ehhez kötöd a uicontrol-ok IsEnabled propertyjét.
A ui szál nem lefagyasztására az aszinkron futtatás lesz a megoldás, ahogy mondod. -
pmonitor
aktív tag
válasz leslie23 #9525 üzenetére
Ha fizikailag egy csoportba tudod tenni azokat a control-okat, amelyeket nem szeretnél használni a művelet alatt, akkor használhatsz groupbox vagy panel controlt, és akkor
panel1.Enabled=false;
vagygroupBox1.Enabled=false;
,
majd ha végeztél, akkor true.Ha nincsenek 1 csoportban, akkor még mindig van olyan lehetőség, hogy 1 listába beleteszed azokat a control-okat, amiket le szeretnél tiltani. Ebben az esetben 1 ciklussal kell végigmenni a lista elemein, és így tiltani/engedélyezni.
http://www.bferi.hu/download.php ; http://bferi.hu/egyeb.php
-
joysefke
veterán
válasz leslie23 #9705 üzenetére
Én sem vagyok guru
N-tier architecture-t próbálok kialakítani
tankönyvekben jól működik....van egy DataAccess, amibe a Repository és UnitOfWork pattern dolgai és az EF Core-specifikus dolgok kerülnek...
Az én személyes nem feltétlenül objektív véleményem erről az EF+UoW/Repository a témáról.
Az Ef DbContext osztálya az már önmagában egy UnitOfWork, benne a DbSet<T> pedig egy Repository megvalósítás.
1,
Ezt becsomagolni egy másik UoW/Repository abszrakcióba csupán azért hogy legyen egy repositorid vagy UoW-öd önmagában semmi értelme.2,
Ha azért csomagolnád be a DbContext-et egy abszrakt, generikus UoW / Repository petternbe, hogy az EFCore egy absztrakció mögé kerüljön, és a felsőbb réteg ne dependáljon közvetlenül az EF felé, akkor ez nemes és jó indok, de saját tapasztalatom alapján nem működik jól.Itt van pld a docs.microsoft.com oldalán egy Generikus Repository UoW sablon ami absztrakció mögé helyezi a Repo/UoW pattern konkrét megvalósítását, az EfCore DbContext-et: Implementing the Repository and Unit of Work Patterns in an ASP.NET MVC Application (9 of 10) | Microsoft Docs
Nekem ezt az absztrakciót mentésre (C/U) a legprimitívebb esetektől eltekintve nem sikerült érdemben használni. Orrán száján ereszt. A relációs adatbázis FK constraintjei illetve hogy az EF change tracker éppen melyik rigojáját alkalmazza fogják meghatározni, hogy egy Update az éppen működik vagy sem. Az relációs constrainttel nincs gondom, de a másik az nekem komoly probléma.
...Jelenleg a Data projectben van egy ViewModels mappám, de logikailag ezeknek lehet a Presentation layerben lenne inkább a helye....
N-layerben az egyes layerek csak lefele dependálnak és ha egy mód van rá, akkor csupán a közvetlenül alattuk levő réteg felé. A ViewModel az prezentációs réteg (az ASP-kontrollerrel együtt).
...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...
Optikailag nem néz ki jól, ha egy több projekt által használt model osztályon olyan speciális attributumok vannak definiálva aminek semmi köze az adott assembly céljához, DE a Te esetedben a "System.ComponentModel.DataAnnotations" az ugye része a Core frameworknek és része lesz a jövőben is és a visszafele kompatibilitás adott lesz. Ezért ez egy "nem-volátilis dependencia", reálisan soha nem lesz útban, soha nem romlik el, max a szemedet fogja szúrni. Szemben mondjuk az EF Core-ral, ami egy "volátilis dependencia": 1-2 évente újraírják és minden verzióugrás tele van funkció-törő változtatással.
Ráadásul ugye a "System.ComponentModel.DataAnnotations" használata vagy nem használata semennyiben nem fogja a tesztelhetőséget befolyásolni, míg a DAL tesztelése vagy tesztekben való kiváltása az egy téma amivel majd foglalkozni kell, szóval a DataAnnotations elhelyezése -szerintem- az utolsó prioritás amin töprengened kell.
szükségem van ... 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.
Én is csak ezeket ismerem. Hogy két irányú mappelésnél mi lenne a probléma, azt nem tudom. N-layer esetén mivel a felső réteg ismeri/hívja az alsót, ezért logikusan a felsőbb rétegnek kell hívnia a mappelést is. (mivel az alsóbb réteg nem ismeri a felsőbb rétegben definiált modellt (fordítva viszont igen), hiszen nincsen oda dependenciája (projekt referálása)). A mappelés az logikailag infrastruktúra kód "plumbing". Minden réteg használhatja (dependálhat felé), ennek megfelelően be lesz betonozva a projektbe.
Egyáltalán helyes a megközelítésem? Köszi előre is!
Ha maradsz az N-layernél, akkor az, hogy minden réteg (ami nem valamilyen mindent átható infrastruktúra (mapper/logging)) az csak lefelé dependál. Ha az EF-Core-DAL-t reálisan ki akarod váltani vagy szeretnéd, ha egy EF Core 6 DAL => EF Core 7 DAL váltás sima legyen, akkor lehet hogy jó ötlet lenne az applikációs logikát a DAL-tól egy DAL interfész segítségével elválasztani, ami a saját önnálló assembly-jében van. Ez a stairway pattern. A DAL megvalósítás interfészen keresztül (amely külön assemblyben van) le van választva a használójától és a megvalósításától is. Ennek van egy pozitív hozadéka: Le tudod fordítani a solutiont működő DAL megvalósítás nélkül is. => És ez visszafele is igaz. Enélkül ha nem fordul a DAL projekt, akkor semmi sem fordul.Ahogy én állnék neki (és ez szubjektív és nem feltétlenül helyes megközelítés):
Dobnám az N-layert publikus generikus repositorival meg UoW-kel együtt.Lenne egy prezentációs projekted (ASP), lenne egy külön konkrét EF-Data access megvalósítás projekted meg lenne egy olyan projekted ami sem a prezentációs sem a data access projektet nem referálja. Ez tartalmazná az entitások modell osztályát is , illetve az összes interfészt amelyeken keresztül mondjuk a perzisztenciát akarja vezérelni. Az interfész pontosan azt és csak azt deklarálná amire a központi projektednek szüksége van. Meg tartalmazná az összes tiszta domain-logika kódot. A lényeg, hogy ez a központi projekted kifelé nem dependálhat volátilis dependenciák (EF Core, Adatbázis) irányába. Dependenciák invertálva vannak befelé.
A cél itt az, hogy volatilis dependenciák hiányában a központi projekted könnyedén unit tesztelhető legyen. Az emlegetett mappelgetés is sokkal kisebb probléma.Üdv
J.[ Szerkesztve ]
-
joysefke
veterán
válasz leslie23 #9709 üzenetére
Két párhozamos dologról volt szó amelyek egymástól valamennyire függetlenek:
A fontosabb döntés:
1,
1a, N layer (Te nyilván háromban gondolkodsz) vs 1b Hexagonal (vagy ahogyan hívni szeretnéd) arch.másodjára
2,
2a, Generikus Repo/UoW mögé rejtett EF DbContext vs 2b Domain specifikus perzisztencia interfészek (nem tudom a nevüket bocsi)Én azt sugalltam, hogy ne próbálj meg tankönyvi N-layert csinálni.
Ezen felül nekem fenntartásaim vannak azzal kapcsolatban, hogy az DbContext-et bezárjuk egy generikus Repo/UoW mögé és majd az "applikációs réteg" használja a az Insert/Update/ etc metódusokat (az eredeti írásodból azt olvastam ki, hogy erre készülsz) .
Szóval anélkül, hogy tudnám, hogy egyáltalán mit akarsz csinálni, nekem az alap hozzáállásom egy újabb kis hobbiprojektemhez amiben van ASP meg DB a következő lenne (a nevek szabadon variálhatóak, csak próbáltam beszédes neveket varázsolni):
MyProjekt.ASP => MyProjekt.Core <= MyProjekt.Ef
Nincsenek rétegek és nincsen sem teteje sem alja, viszont van közepe meg vannak a többiek. A nyilak a dependencia irányokat mutatják.
Mindenki a közepét referálja, a közepe viszont nem referál olyan dolgokat amelyektől nem akar függeni. Nem referálja sem a saját EF vagy ASP függő projektjeidet sem magát az ASP vagy EF frameworkot
Amikor a közepe valamit akar a "széllétől", akkor azt egy saját magában definiált interfészt használva teszi meg
Ennek két hatása van:
-a közepe mindenki nélkül, önmagában is fordul, ez megteremti a lehetőségét, hogy könnyedén unit teszteld
-a közepe a függőségeket (pld EfPerzisztencia) DI formájában (leginkább konstruktoron keresztül) kapja meg, ez pedig megint erősíti a közepének a unit tesztelhetőségétAhhoz, hogy ez megvalósuljon, a dependenciák invertálva vannak:
Ha ez egy N-layer arch lenne, akkor az "Application layer" referálná a DAL-t (vagy közvetlenül, vagy interfészen keresztül, de az interfész is logikailag a DAL-ban lenne).
De itt nem, itt ez fordítva van. Itt amit a DAL (ábrán MyProject.Ef)-tól a Core használni akar, az interfész formájában definiálva van, és ez az interfész a "Core" része és a DAL valósítja meg.Másrészt a "Core"-ban lévő dolgoknak amelyek valamit akarnak a széllétől (pld perzisztálni) nyilván szükségük van olyan objektumokra amelyek ez meg is tudják csinálni (megvalósítják azt az interfészt amit a "Core" adott osztálya éppen használni akar). Ezek az objektumok DI-jal kerülnek be leginkább mint konstruktor paraméter. A DI konténert a te esetedben az ASP-s template ConfigureServices-ban tudod konfigurálni (ez gyak. az applikáció belépési pontjánál van).
Visszatérve a konkrét kérdéseidhez:
-Az ASP-s Controllerek, View-k Modell-ek (azok amelyek a Html-be szállítják az adatot) azok mind az ASP-s projektedbe kerülnek.-A Core-ba kerül minden "domain model" (első körben az entitásaid is mindenképpen akár van annotáció rajtuk akár nincs) meg mindenféle logika ami ezeket érinti.
-A "Core"-ból mindenféle frameworkos stabil osztály felé mehet dependencia, pld a DataAnnotation-t amit korábban felvetettél reálisan nem fog problémát okozni és a tesztelést sem nehezíti meg.
-Mehet külső dolgok irányába is, ha azok nem nehezítik a tesztelést meg nem akarod őket soha lecserélni. pld Newtonsoft.Json.
-A "Core" specifikálja interfészekkel, hogy mit kell tudjon a perzisztencia (meg egyéb függőségek amelyektől akar valamit) és ezek az interfészek a core-ban vannak.
-A külső projektekben lévő függőségek pedig megvalósítják a Core-ban azt/azokat az interfészeket amelyek miatt nekik egyáltalán helyük van a szolutionben.
Tehát ha maradsz a generikus repositorinál, "2a" akkor a Te általad tervezett ...
IPersonRepository
,IProductRepository
, ...IRepository<T>
...IProductRepository
...IRepository<Product>
interfészeid is mind a "Core" ba mennek,egy a lényeg, a Core-ba nem kerülhet be EF függőség (tehát az interfészeid metódusainaknak sem lehet EF ben deklarált paramétere, visszatérési értéke). A Repository interfészed konkért megvalósítása viszont az Ef-projektbe kerül.
Vagy dobod a generikus repository-t ez a "2b" és ekkor a Core-ban nem a fenti teljesen álltalános perzisztencia interfészek lesznek mint hogy az IPersonRepository-n lesz mondjuk egy void Save(Person person), hanem lesz mondjuk egy (csak a példa kedvéért)
IPersonCommands
{
void SetProfileImage(int personId, Picture picture);
}
ugyanúgy a "Core"-ban, ezt meg mondjuk megvalósítja egy EfPersonCommands az Ef projektben. Szintén csak a példa kedvéért:EfPersonCommands: IPersonCommands
{
IDbContextFactory<PersonContext> _factory
// vagy Optionst injektálsz (az a preferált ebből szintén elő tudsz állítani Contextet amikor kell) vagy factoryt, mindkét opció tiszta lesz DI-jal,
EfPersonCommands(IDbContextFactory<PersonContext> factory)
{
_factory = factory // throw if null..
}
void SetProfileImage(int personId, Picture picture)
{
using var context = _factory.Create();
//csinálsz valamit
context.Save() <= tranzakció
} <= dbcontext dispose
}
A kliens pontosan azt kapja amire szüksége van (cserébe potenciálisan több metódusod lesz), a megvalósításba már bele van csomagolva a tranzakció.
2a vs 2b az részletkérdés (könnyen tudsz változtatni bármelyik irányban), 1a vs 1b viszont egyáltalán nem.[ Szerkesztve ]
-
dqdb
nagyúr
válasz leslie23 #9789 üzenetére
Tegyél be egy Fiddlert a webreference-et használó hívási láncba, és máris lesznek kérés-válasz példáid. A cím az ez, azaz az .asmx címe, az actionök azok namespace-ek/típusok, nem pedig konkrét címek.
Érdemes átfutni gyorsan a szabványt, hogy átlásd a séma felépítését.
tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
dqdb
nagyúr
válasz leslie23 #9792 üzenetére
A Fiddlerrel ha jól értem nekem kellene felépítenem a request XML-t.
Rosszul, ahogyan martonx is írta, a Fiddler csak egy proxy, amin keresztül bonyolítva a forgalmat lehet monitorozni a kéréseket és válaszokat. Opció lehet még a message logging és tracing bekapcsolása.tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek
-
martonx
veterán
válasz leslie23 #9798 üzenetére
Manapság, amikor a gépeknek van minimum 8GB ramja, szerintem semmi se akadályoz meg abban, hogy ramban tárold, amit csak tudsz. Mi lehet a legrosszabb, ami történik? A winforms appod memória használata felmegy 1-2GB-ig? Na ügy
Az első kérdésedre elég egyértelmű, hogy mi történik. Ha nincs a connection stringben a timeout beállítva, akkor a default azt hiszem 30s.
Azt írod, hogy ezek egyenként 5-15 másodpercesek. Igen ám, de nem nehéz belátni, hogy ha ilyen queryből futtatsz 15-öt párhuzamosan, akkor szegény DB szervernek sem 5-15 másodpercébe fog kerülni egyet-egyet végrehajtani, hanem ki tudja mennyivel többe (SQL szerver erőforrásaitól függ). Ergo simán elérheti a 30 másodpercet is 1-1 lekérdezés ideje, és voilá, máris kapod a hiba üzenetet. Legalábbis szerintem ez történik, és ezért is javul meg, amikor connection stringben belefoglalod a korlátlan timeout időt. Vagy egyszerűen csak megölöd a DB-t, és timeout időn belül még új connectiont létrehozni sem sikerül felé.
Biztos, hogy valami ilyesmi lesz a problémád forrása.Én kérek elnézést!
-
sztanozs
veterán
válasz leslie23 #9798 üzenetére
COM-ot nem fogsz tudni parallelizálni szerintem, Excel COM csak egy instance-el dolgozik, össze fog akadni biztosan.
Az adatbázis más kérdés, de ha feldolgozási oldalon van a probléma, akkor nem fogsz nagyobb telejsítményt kisajtolni belőle így sem.Amúgy adatbázisban legtöbbször az a gond (INSERT-nél), hogy egyesével viszik fel a rekordokat, így minden utasítás külön tranzakció, és baromi nagy az overhead. Ha fel tudod vinni ezresével, vagy az egészet egszerre, akkor sokkal gyorsabb lesz már ettől is.
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
sztanozs
veterán
válasz leslie23 #9804 üzenetére
Szerintem a gond ott lehet, hogy olyan adatforrásod van, ami nem tolerálja a parallel használatot.
Esetleg próbáld meg a SqlDataAdapter és DataTable instance-eket is Using-ba rakni. Mondjuk a példák, amiket láttam SqlCommand-dal voltak (ott is berakták a Commandokat using-ba, hogy rendesen terminálva legyenek).
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
rgeorge
addikt
válasz leslie23 #9804 üzenetére
Biztos, hogy a SqlDataAdapter-t is szabályosan kellene használni (IDisposable). A probléma szempontjából nem releváns, de a DataTable is az. Simán előfordulhat, hogy a nem lezárt (dispose-olt) adapter miatt a connection sem zárul le.
Picard: "What we leave behind is not as important as how we've lived. After all, Number One, we're only mortal." Riker: "Speak for yourself, sir. I plan to live forever."
-
joysefke
veterán
válasz leslie23 #9798 üzenetére
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.
Igen, érdemes kódban is elkülöníteni az egymástól nagyon különböző feladatok megvalósítását. Ezzel a hibák kezelését könnyíteni tudod.
Fogod a Parallel.Forech-edet és ahelyett hogy az abban levő kód (delegate) csinálja a az SQL lekérdezést ÉS az Excel interop hívását:
A Parallel.Foreach csinálja csak
-1. az SQL lekérdezést /ahogyan eddig/, az adatok esetleges modellekbe való transzformálását,
-2. majd az eredmények összefésülését. <= ennek thread safnek kell lennie.A 2.-höz használhatsz BlockingCollection<T>-t ami thread safe. A ForEach által futtatott kód az SQL lekérdezés eredményét kiszedi a readerből, opcionálisan áttranszformálja valami modellbe (ez a "T") majd ezt beszúrja a BlockingCollection<T>-be.
A Parallel.Foreach futása után egyetlen szálon végigiterálsz a A BlockingCollection-ön és feldolgozod a kinyert és összefésült adatokat => meghívod egyenként az Excel interopodat minden egyes adatelemre.
[ Szerkesztve ]
-
sztanozs
veterán
válasz leslie23 #9811 üzenetére
Alapból szinte semmi nem thread safe.
Persze lehet, hogy változott valami ebben a témában az elmúlt néhány évben, de őszintén szólva kétlem.[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
Alexios
veterán
válasz leslie23 #9817 üzenetére
Ha a kérdés az, hogy van-e még piaci igény WPF fejlesztőre, a válasz igen. Az, hogy hosszútávon mennyire éri ebbe most jelentős energiát fektetni más kérdés, de nekem is jelentős WPF fejlesztés volt pl. az előző munkahelyemen.
WinUI3/MAUI-ra amúgy elég könnyen átvihető a tudás, de én nem biztos arra alapoznék, hogy ezek nagyon el fognak terjedni a jövőben, desktop alkalmazásnál jó vagy sem sokkal inkább az electron és hasonlók az irány, én inkább efelé mennék el ha most 0ról akarnék desktop fejlesztéssel foglalkozni.
Ú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