Logování uživatelských akcí
- Kajda23
- Člen | 42
Ahoj,
řeším takovou spíš filosofickou otázku (jak to tak bývá s praktickými
dopady), a to: chci logovat a sledovat uživatelské akce – že se někdo
zaregistroval, že změnil tenhle produkt na eshopu, atd. Jde tedy o jiný log
než dělá třeba Tracy.
Kam tohle logování patří? Je to záležitost modelu či presenteru? Nemyslím, že takovou věc řeším sám, jak to řešíte vy?
Představa je taková, že mám DB tabulku, kam to sypu, classu Logger, kterou si budu injektovat do …to je ten otazník… a logovat co mi přijde vhodné. Na první pohled se přikláním k presenteru, protože u modelu vidím nějaké možné problémy (např. Logger by měl asi znát uživatele, ale když budu chtít logovat přihlášení v authenticatoru, vzniká circular reference, protože User má Authenticator, Authenticator chce logovat a Logger chce Usera). U presenteru podobné problémy nevidím (na první pohled).
- CZechBoY
- Člen | 3608
Tak záleží jaký všechny informace chceš mít k dispozici. Jestli businessový tak v modelový vrstvě je máš k dispozici, jestli ti stačí jen nějaký IDečka a název presenteru tak Presenter.
Taky mám logger o cca 2 tabulkách (log tabulka, parametry url/entity) a asi mi to i stačí.
V modelu musíš mít dostupnýho i uživatele… jak jinak bys udělal např. objednávku kdybys nevěděl koho je? :-) To stejný u přihlášení, taky víš koho si přihlásil.
- Kajda23
- Člen | 42
Jde mi spíše o to, jestli logování do presenteru nebo modelu vůbec patří. Všechny informace, který chci logovat, mám jak v modelu, tak ale i v presenteru, protože tam volám tu akci/model, který mi ty informace poskytne.
Ne všechny modely musí mít uživatele, ale pokud ho potřebuji, DI mi ho tam samozřejmě pošle. Pak je tu ale třeba admin, kde modelu jako takovému je fuk, jaký je uživatel, ale někdo musí být přihlášen, aby se k modelu vůbec dostal – a já chci logovat kdo.
No a u toho přihlášení je to specifická situace, pokud to nechci udělat v presenteru, musím zalogovat už v authenticatoru právě přihlášeného usera, k tomu potřebuju logger, který ale potřebuje usera vyžádaného přes DI a mám circular referenci jak vyšitou.
- CZechBoY
- Člen | 3608
jo, určitě bych si ho radši předával parametrem než konstruktorem.
Klidně si udělej na všechno fasádu a ke všem parametrům co posíláš z presenteru přidáš ještě id/identitu aktuálně přihlášenýho uživatele. V té metodě fasády pak jen zavoláš službu co si volal předtím + zaloguješ co se stalo/nestalo.
Jinak celý tohle se dá ještě řešit přes eventy.