dotNETportal.cz

Ahojte, pokusim sa popisat problem s ktorym sa uz nejaky cas trapim.

Vyvijam aplikaciu (v ramci nejakeho samostudia) ktora by raz mala byt e-shopom. Aktualne pouzivam MVC 5 a EF 6, ale EF 6 chcem nahradit Dapperom. Koncept maleho ORM ma zaujal viac ako EF, navyse je vykonnejsi. V zasade to asi nie je podstatne.

Ide mi o to, ze by som chcel izolovat DAL vrstvu od BLL vrstvy. Aktualne su zlepene a pre ucely projektu to nie je neprekonatelny problem, ale chcem to urobit spravne. Momentalne to vyzera tak, ze mam nejake DB modely do ktorych EF mapuje data z DB. Tie sa nasledne preklopia do Biz modelov ktore maju identicku strukturu, co je mozno zbytocne, ale do buducna sa pocita aj s nejakou logikou (no vlastne skor dufam, ze tomu neskor dam nejaky vyznam).

Co by som ale chcel docielit je, ze az sa teraz rozhodnem vymenit EF za Dapper, alebo inu DAL vrstvu, malo by to ist hladko a bezbolestne. Moja predstava je taka, ze vytvorim interface (zrejme viac), alebo nejaku abstraktnu classu ktora bude obsahovat metody pre pracu s DB (create, update, delete ... ). Nova DAL vrtsva bude mat nejaku Provider/Service/Facade class ktora bude dedit od tohto "interface" a tiez ju bude implementovat.

Jediny problem aktualne vidim v objektoch/modeloch/entitach. Co by vlastne DAL mala vracat, co by mala prijimat ako parametre atd. Povedzme, ze mam metodu

public List<nieco> GetProducts();

ide mi o to, ze by asi nemala vracat objekty ktore pouziva EF. Druha moznost je, ze by mohla rovno vracat nejake BizModely, ale tym padom by DAL musela referencovat BLL a nie som si isty, ze je to spravne. Ina moznost je, ze by som BIZ modely vlozil do samostatnej DLL a pouzival ich v DAL a BLL. Asi najspravnejsie je pouzit nejake rozhranie, cize nieco ako:

public List<IProduct> GetProducts();

definovane zase mozno idealne v samostatnej dll. Tu mi ale vadi, ze tie interface zase neviem napisat, pretoze konkretne Product ma vacsie mnozstvo properties a z toho by vznikali velke rozhrania a to asi tiez mozno nie je najlepsi pristup.

Ospravedlnujem sa, mozno sa pytam hlupo, ale niekto snad pochopi o co mi ide a trochu mi s tym pomoze. Dost by som to ocenil. Vdaka :)

Ver mi, realne abstrakce DAL nefunguje. Castecne to vysvetluje tu:

https://www.youtube.com/watch?v=BruPcBDo...

U relacnich DB a jejcih switche to je jeste realne.., ale to neni to proc to delas,. ty chces mit proste mznost zamenit zpusob ulozeni (at uz opravdu ulozeni, nebo koomunikaci) a ne jen mit moznost zmenit pristup k Relacni databazi. Musis resit prilis veci a dostal by si se do mrtveho bodu.

uz kdyz si vezmu transakci,, v EF resis lifecykle DBContextu,.. kdybys chtel switchnout treba na rucni psani SQL, budes muset sam handlit transakce, commandy atp.. A opet to nei uplne jednoduche udelat..

Muzes se tedy snazit abstrahovat DAL, ale ta zmena nikdy nebude uplne bezbolestna.

To video si pozriem, dakujem.

Uprimne, nemam s tym prilis vela skusenosti a co do navrhu architektury (ak sa to tak da nazvat) som amater. Moja idea skratka bola vytvorit nejake genericke rozhranie ktore mi umozni pohodlne pripojit/vymenit novu DAL bez toho aby som musel upravovat BLL. DAL by vlastne bol taky komplexnejsi plugin. EF zase tak velmi nepoznam (preto som sa rozhodol ho pouzit), kedze nie som fanusik velkych a tazkych ORM a je mozne, ze ma svoje specifika ktore mi situaciu komplikuju.

V kazdom pripade asi pri navrhu DAL/BLL existuju lepsie a horsie pristupy (aj ked mozno nikdy nie dokonale) a rad by som to urobil aspon trochu poriadne :-) Ako som pisal, je to skor taky EDU projekt.

Abstrakce DALu ti muze usnadnit (a většinou usnadní) vyměnu storu za jiný,.. nikdy ho ale úplně bez problému nevyřeší.. Jakmile uvidíš to video tak pochopíš.

většinou co je takový základ, co ti hodně usnadní, je mít kvalitní Unit Of Work, ale rozhodně ne ten, který najdeš na stránkách microsoftu, kde porušují spoustu principů, například Open/Closed.

Špatný UOW poznáš tak, že má v sobě repozitáře.

Unit Of Work a repozitáře mě trápí už dlouho. Prošel jsem hromadu různých tutoriálů a příkladů a všude je to řešeno jinak. Nejčastěji UOW obsahuje repozitáře, což jak píšete je špatně. Byl by odkaz na nějaký příklad správného použití UOW v ASP.NET MVC společně s IoC kontejnerem? Děkuji.

Hodne blizko je tomu UOW co předvádí Tomáš Herceg ve videu na wug.com s názvem tuším "zajímavé návrhové vzory". Má tam sice pár chyb v kódu, který pravděpodobně ani nepujde zbuildit a nemá tam dořešené určité věci, ale základní pointa je správně.