Nejvíc mi vyhovovalo asi následující:
Kontroler je jenom hlupáček, co ho vlastně zavolá view, že chce nějaká
data.
On veme data z db contextu, v nějaké neupravené podobě je pošle do servisy,
která je přechroupá na patřičný viewModel, který kontroler pošle do
view.
Controller je tedy jediný, kdo šahá do db.
Pak tady co view, to viewModel(včetně edit, create,atd...) - to může znít jako pruda, ale když ti trochu rozkvete, je to pohodlnější.
Tohle je dobrá otázka, zajímalo by mě, jak to dělají ostatní.
Naozaj si myslíš, že je vhodné aby "jenom hlupáček" spravoval dáta? A
čo v prípade, že potrebuješ volať rovnaké query alebo ešte lepšie x
queries za sebou z viacerých miest? Kopa duplicitného kódu.
Kým tvoj servis len obaluje prevod modelu na viewmodel, tak mi príde
vhodnejšie aby práve obsahoval nejaký repository a až ten mal dbcontext.
Single responsibility 
Myslím, že lepší než odpovídat si na otázku "jak" je lepší si odpovědět na otázku proč. Odpovědí na "JAKy" je mnoho a vesměs mezi "jaky" budou jenom drobné nuance.
Pokud bych měl odpovědět na otázku proč, tak protože když už jsem v tom M V C a tak budu chtít to C testovat. No a tomu podřídit ten zbytek.
Z tohoto pohledu mi přijde vhodná kombinace s lehnotonážními kontrollery(bez nějakých závislostí na webových záležitostech) kterým podsunu jakkoli (třeba přes IoC) můj IRepository<MojeDato>. Přičemž IRepository<MojeDato> může být jenom nějaké MemoryStorage nezávislé na databázi a tím pádem zase dobře otestovatelné.
No, ono je jedno jestli budu 10x psát v kódu db.Users()... nebo si napíšu nějakou servisu, kde bude metoda, kterou budu 10x volat....
V jistém smyslu slova máš pravdu, je to jedno. Když to ale budeš chtít upravit, tak v té "servise" jak píšeš, to upravíš jen jednou a ne 10x...
Zobrazeno 6 zpráv z 6.