Hirdetés

Keresés

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

  • joysefke

    veterán

    válasz Alexios #9707 üzenetére

    Nekem ezzel és ehhez hasonló generikus repositorikkal: Implementing the Repository and Unit of Work Patterns in an ASP.NET MVC Application (9 of 10) | Microsoft Docs

    Az a bajom, hogy az ilyen metódusok mint Update<T>(T entity) , esetleg Save<T> (vagy Upsert<T>), Delete() elhitetik a hívó oldalon, hogy ennyire egyszerű a perzisztencia, hogy meghívod őket utána a UoW-ön egy Save()-t és kész. És hogy ez mindenre működik amit típus paraméterként át tudnak adni.

    Holott
    -nem feltétlenül értelmezhető/működik minden lehetséges T entitás típuson az összes művelet,
    -nem hívhatsz egymástól függetlenül mindenféle Repository metódust egy UoW tranzakción belül,
    -illetve lehet hogy mondjuk az Update<T>(T entity) működik, de mondjuk az adott konkrét entitásra nem a mindenkire érvényes implementáció-t akarná a kliens kód hajtani.
    -Az is lehet hogy van egy entitásod ami már trackelve van, mivel az egyik repository metódus impliciten előkerítette, majd a másik ráhív egy attach-ot a már trackelt entitásra. => exception, holott amit a kliens el akar érni annak van értelme és meg is valósítható lenne egy tranzakción belül (DB engedné egy megfelelő SP-vel, illetve engedné az EF is, ha ügyesen lenne megcsinálva).

    Ami nekem sokkal szimpatikusabb:

    Kliens kód kap egy interfészt amin azok a perzisztencia műveletek vannak amelyekre a kliensnek konkrétan szüksége van.

    Az interfészt megvalósító osztály EF-függő, az adott metódusa pedig közvetlenül indít EF dbcontext-et (lehetőleg DI-on keresztül szerez ehhez egy DbContextFactoryt vagy azzal egyenértékű opciót amiből Contextet lehet előállítani), közvetlenül attach-csolhat entitást és állít EntityState-t, illetve menti a tranzakciót. Tehát kihasználja az EF tényleges tudását és azt biztosítja a hívónak amire annak szüksége van, lehetőleg egyetlen hívásból.

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