Új hozzászólás Aktív témák

• #9706 joysefke veterán leslie23 #9705

  Új Válasz 2022-01-23 17:21:41 #9706

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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.

Új hozzászólás Aktív témák