Hirdetés

  2. Fórumok
  3. Szoftverfejlesztés
  4. C# programozás
Legfrissebb anyagok
PROHARDVER! témák
Mobilarena témák
IT café témák
GAMEPOD témák

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

  • #9949 joysefke veterán bandi0000 #9945
    Új Válasz #9949
    Ú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 bandi0000 #9945 üzenetére

    Ahogy már írták a DbContext már önmagában is repository és unit of work.

    Innen kezdve ha becsomagolod egy generikus repository + UoW absztrakcióba, akkor azt nem a funkcionalitás miatt teszed, hanem hogy elfedd a EntityFramework-öt, tehát hogy a repositoryt használó kód ne tudja magát az adott EfCore verzióhoz/funkciókhoz láncolni.

    akkor van valami köztes réteg még a felület és az adatbázis közt, ami pl olyan feladatot látna el, hogy mentéskor ha ügyfelet és autót akarunk menteni, akkor a felületen kb csak annyi hívás legyen, hogy: SaveClientWithCar(Client client, Car car) és ez a köztes réteg lezongorázza a mentéseket ID generálással és beállítással?

    Igen, a repository egy low level absztrakció az adathozzáférési rétegben.
    Ha van egy featuröd (amit mondjuk egy UI page valósít meg) akkor annak a featurenek lesz konkrét igénye hogy adatokat tudjon olvasni a DB-ből (amit megjelenít a user számára) illetve a user által módosított adatokat perzisztálni tudja DB-be.
    Az adatok formájára nézve a feature nyilván konkrét kívánalmakat fogalmaz meg. (e.g. mutasd az összes usert akinek van autója az autója típusával és évjáratával együtt) illetve meghatározza, hogy melyik adatmorzsa módosítható és melyik nem a feature kontextusában.

    Itt érdemes egy a featuret kiszolgáló, a repositorynál magasabb absztrakciós szinten lévő, data access service osztályt definiálni ami a repositoryra támaszkodva keríti elő a featuret hajtó kód számára az adatokat illetve menti el a változásokat. A repository-ból visszaadott adatokat arra a formára tudja adaptálni amilyen formában a featurnek szüksége van rá.

    egy alternatíva lehet, hogy hagyod a repository patternt és ezeket az adott featuret kiszolgáló data access service osztályokat közvetlenül az Ef DbContext-re építed (DI-t használva nyilván) aztán a featuret hajtó logika használja ezeket (ezek interfészét).

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