soy-grep
commented
8 years ago Nie som si istý, či mojími myšlienkovými pochodmi vyriešim problém opakujúceho sa kódu v kontroleroch... ale myšlienka Kontrolera ako iba vstupný bod mi je blízka.
Takže v princípe by sme zaviedli medzičlánok - niečo medzi Controller a DataAccess. Niečo, čo by zhromažďovalo business logiku "modulov" ako Rooms, Equipments, Rezervácie... Tá sa z pohľadu editácie záznamov často opakuje.
Predpokladám že v budúcnosti budeme chcieť riešiť rôzne komplexnejšie operácie napr. nad Doménovými objektami Miestností - proces samotnej rezervácie môže zahŕňať žiadosť o uzamknutie samotnej miestnosti na čas rezervovania, overenie či na takúto rezerváciu má užívateľ vôbec právo, budeme riešiť uzamykanie záznamov (Pessimistic Concurrency). A nezdá sa mi v pohode, aby kontroler Rezervácií liezol priamo do Repository užívateľov a miestností. Také isté úkony nad užívateľmi a miestnosťami možno bude chcieť vykonávať aj iný kontroler, nebodaj nejaký Background Worker servra... preto sa tu pýta ten medzičlánok.
Z pohľadu Responsibility sa na Controller pozerám podobne ako to naznačil @Burgyn - vstupná brána do aplikácie. Controller by mal informácie z Requestu podsunúť správnym Business Objektom, tie ich spracujú a vrátia výstup. Tento výstup Controler sformátuje do Response. Na druhú stranu Repository je zodpovedné IBA za čítanie a zapisovanie dát. Tam určite nepatrí logika samotnej rezervácie abo nejaké prepočty.
Z pohľadu závislostí by teda fungoval vzťah: Controller -> Business Logika -> Data Access
Práve dvojica [Business Logika -> Data Access] z môjho pohľadu predstavuje niečo ako Modul... (Ten Data Access bude do Modulu injektovaný, takže je stále implementácia DAL nezávislá). Tento prvok by mal byť ideálne natoľko nezávislý, že by mu malo byť jedno, kto využíva jeho metódy - či WebApi servis s kontrolermi, alebo nejaký extra proces importujúci dáta z iného zdroja. To znamená, že v krabičke modulu by sme sa nemali hrať s pojmami Request/Response...
V princípe by sa tento prístup dal aplikovať aj do desktopovej MVVM aplikácie, kde by bol vzťah View -> ViewModel -> Business Logika -> Data Access... Ale tam môže Modul obsahovať aj prvky prezentačnej vrstvy z danej domény... Ale to len tak pomimo.
Toľko moje myšlienky, Neviem či to nie je "Overkill" pre našu pomerne jednoduchú aplikáciu... :stuck_out_tongue_closed_eyes:.
Burgyn
Problém: V súčasnosti máme RoomsController / EquipmentsController a UserControllers, ktoré majú zväčša rovnaké metódy a ich telá.
Chceme to zjednotiť do spoločnej generickej triedy, ktorá by tieto základné operácie vedela zastrešiť.
Navrhoval som, aby sa to neriešilo generickým predkom controllera, ale aby to bolo v samostatnej business triede. Jednotlivé controllery by len požiadavky preposielali na spomínanú triedu. (dôvodom je to, že controller je v podstate len vstupný bod pre request a nemala by sa v ňom riešiť priamo business logika)
Konkrétne riešenie tu môžeme rozdiskutovať, keď sa to začne riešiť.