C# - asp.net core helyzete hazánkban

C# - asp.net core helyzete hazánkban
2018-06-29T20:21:10+02:00
2018-07-02T12:01:40+02:00
2022-10-18T17:35:35+02:00
  • Tok jogos  De majdcsak utoleri a nagytesot
    Mutasd a teljes hozzászólást!
  • Ahogy SubZeroXL-nek is írtam: hasonló a helyzet, viszont vannak olyan közepesen bonyolult query-k (5-8 outer joinolt tábla stb.), amihez viszont ne kelljen már SP-t/View-t írni, ezek EF alatt standard-nak számítanak. És ez lenne az EF egyik lényege, hogy relatív könnyen kéne tudnom adatbázis engine-t váltani. Jól nézünk ki, ha csak a CRUD működik stabilan.

    A hatékonyság pedig helyzetfüggő: két query ott, ahol egy is elég lenne, az esetlegesen komoly teljesítménycsökkenéssel jár, szóval nem mindig járható út.

    És nem is kell ilyeneket csinálni: szépen működik a kód, csak sajnos egyszer csak törik. Aztán majd javítják, valamikor. Na, ez a gondom, MS-nél nem ehhez vagyok szokva.
    Mutasd a teljes hozzászólást!
  • Igen, az igazán bonyolult query-ken marad az SP és a View (én utóbbit használom és azt szűröm). Csak akkor lassan ott tartunk, hogy így minek EF?

    Ha most komolyabb projectet indítanék Windows alatt, elgondolkodnék az ASP.NET Core / EF 6.x felálláson: az egy kiforrott lib. Az EF Core sajnos még nem az.

    Egy megjegyzés: mint írtam, a példának hozott bug javításra került tavaly novemberben, újra gond nélkül lehet használni az eredeti kódot, nem kell workaround.
    Mutasd a teljes hozzászólást!
  • Szia!

    A Projection with nested projection problémában az a ToList a projection közepén 1 query-ben nemtudom mennyire gyakran alkalmazott dolog, de szeritnem ezek indig megoldhatóak máshogyan.

    Hatékonyság miatt is. Mi is inkább a "Split it explicitly into two queries and then combine the results into the DTO afterwards."-t alkalmazzuk, amit az egyik hozzászóló javasol is.
    A tesztelhetőség miatt is, az egyszerűbb függvényeket választjuk, amikor nagyon összetett linq query-t kell irni EF-en keresztül, akkor pedig sokszor SQL-functiont/tárolt eljárást írunk, mert az könyebben optimalizálható, és jobban tudjuk mi lesz a tényleges query (De ez minden ORM-nél igy szoktam, nem bizok bennük :D)

    Ritkán írunk ilyen query-n belül referenciátadogatós, toListben-select-ben toList dolgokat.

    Persze ez nem mentség! Ha a FW lehetőséget biztosít ilyenre, akkor működjön, csak mondom, hogy nekünk valószínűleg azért nem okoz gondot, mert pure(abbak) a functionjeink, és csak annyirt építünk az EF-tudására ami miatt gyorsabbb a fejlesztés mintha nem lenne, de nem visszük túlzásba (ha le kéne cserélni valami másra az is gyorsan menne).

    Amugy én a NEM Core-os változatban is mindig igyekeztem kerülni az ilyet, ha tudtam. Persze sokszor jól jön ez az összetett change-tracking :)
    Mutasd a teljes hozzászólást!
  • Szia!
    Amit csináltunk ott az egyik modul csak sima CRUD-os képernyőkből áll. Ott semmi gond nem volt.   A másik egy dashboard, ami csillió rekordokból aggregál, oszt szoroz stb. Ezek elítélhető módon tároltakban vannak megírva, és a repositoryban FromSql-el  hívjuk őket az EF-en keresztül.  EF el nem lehetett elfogadható idő alatt lefuttatni ezeket lekérdezéseket.  Mivel én tartottam az EF sebességproblémáktól , javasoltam hogy fontoljunk meg egy  Micro ORM-et, de az ötlet a kényelem és a bővett funcionalitás oltárán feláldozásra került.

    A 2. projectnél még az alapadat táblák karbantartásánál járunk.
    Néztem mik okoztak gondot Neked, van rá workaround még ha nem is szép a megoldás.
    Mi is 2.0.3 -on vagyunk, csak akkor fogunk váltani ha az összes teszt lemegy a 2.1-ben is.
    Én is úgy látom mintha az EF olyan kis mostohagyerek lenne az ökoszisztémán belül.  
    De a bosszankodáson kívül mást nem tudunk tenni egyenlőre.
    Mutasd a teljes hozzászólást!
  • Nincsenek problémáitok EF-kel?

    Én kisebb, saját projectet futtatok benne (hogy valami képet adjak róla: kb. 100-120e sor, HelloWorld-nél jóval bonyolultabb, de nem több emberéves kategória), és minden nagyobb EF verzió ugráskor törnek egyes query-jeim, amelyek túlmutatnak az alap CRUD-on. Ráadásul futásidejű problémák jönnek elő, szóval csak konkrét teszteléskor derül ki az upgrade után, hogy ami eddig stabilan működött, az mostantól nem.

    Köztük ilyen alapvetőek vannak, mint pl. ez. A bug bekerült a végleges EF Core 2.0-ba, holott, mint látható, a Preview 2-ben már jelezték azt. Utána újabb 3 hónap után került javításra az EF 2.0.3-ban.

    Most itt az EF 2.1(.1): két újabb buggal küzdök, amit eddig találtam (pl. 2.1.x a DateTime default-ját '0001-01-01T00:00:00.0000000'-nak generálja, ami így konverziós hibát okoz - gond nélkül működött eddig).

    Most ASP.NET Core 2.1.1-et használok 2.0.3-ra downgrade-elt EF-kel.

    Szóval bár maga az alap framework valóban stabil, gyors, okos, rugalmas, én nagyon sokat szívok az EF-kel. Az utóbbi gyakorlatilag kezd JS-életérzés lenni: új verzió -> nem tudhatod, mi törik meg legközelebb. Kijön az új verzió, ketyeg a lejáró support idő, közben meg további hónapokat kell várni, mire valóban használható lesz.

    Tapasztalatok ez ügyben?
    Mutasd a teljes hozzászólást!
  • Mi is erre alapozzuk a jövőt. A második projektet csináljuk benne, de a cégem 20 éves működése alatt elkészült valamennyi szoftvert ebben a stackben fogjuk újraírni. A jelen felállásban Ubuntu
    Linux VPS-en  PostgreSQL adatbáziskezelővel használjuk. Dockerizálás folyamatban.
    Kliens oldalon Angular 5 van.  Nagyon jól működnek együtt.

    Stabil, gyors, nagyon kicsi erőforrásigénye van.
    Mutasd a teljes hozzászólást!
  • Mi 2 projektet is atadtunk mar benne. Teljesen jol muzsikal, jo az ecosystem, es a community is egyre erosebb. 
    Microservices es Serverless kornyezetben abszolut nyero a Node.JS mellett  (sok otletet atvettek innen) de megis megvan amit en pl. szeretek a C# ban.

    Kicsi, gyors, olcso. Jon fel mint a talajviz :) 
    Biztos van akinek nem szimpi, az majd leirja
    Mutasd a teljes hozzászólást!
  • Azokat szeretném kérdezni, akik jártasak az ASP.Net világában, hogy mennyire kezdték el használni a cégek a Core-t - mennyire van tervben egyáltalán?
    "Sajnos" az összes fejlesztő ismerősöm a c++ vagy a java világban jártas.

    Pár éve már "tavaszi kávét" fogyasztok, de most jött el talán az a pillanat, amikor le szeretném tenni. Úgyis munkahely váltáson ügyködök, most jöhetne egy komolyabb váltás is. Szeretem a java nyelvet és a köré épült világot is, de vannak bizonyos pillanatok, amikor inkább nyűg használni a megoldásait, mintsem öröm. Most még beleférne az is, ha visszamennék magasabb junior fizetésre is.

    Álláshirdetéseket böngészve találtam már 'kórosat' is, ezért bizakodó vagyok, hogy nem leszünk 2-3 éves lemaradásban ezen a téren.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd