K personalizaci obsahu a reklam, poskytování funkcí sociálních médií a analýze naší návštěvnosti využíváme soubory cookie. Informace o tom, jak náš web používáte, sdílíme se svými partnery pro sociální média, inzerci a analýzy. Partneři tyto údaje mohou zkombinovat s dalšími informacemi, které jste jim poskytli nebo které získali v důsledku toho, že používáte jejich služby.
Používáme nezbytné cookies pro fungování webu a s tvým souhlasem také analytické a marketingové cookies.
Zajišťují základní funkce, bezpečnost a služby, které sis vyžádal. Nelze je vypnout.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| ITnetwork | ITnetwork | Provoz webu, relace, přihlášení a uložení nastavení cookies. | PHPSESSID, auth_token, sid, itn_consent_impression, __Host-itn_consent | Relace až 1 rok |
| Google Tag Manager | Správa značek a načítání měřicích nástrojů webu. | Žádné | Neukládá se | |
| Google Fonts | Načítání typografie webu. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele | |
| Google Hosted Libraries | Načítání potřebných knihoven a stylů webu. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele | |
| Google reCAPTCHA | Ochrana formulářů a webu před zneužitím. | _GRECAPTCHA, rc::a, rc::b, rc::c, rc::f | Relace až 180 dní | |
| YouTube | Přehrávání vloženého video obsahu. | localStorage, IndexedDB; cookies after playback interaction | Relace až trvalé úložiště | |
| Vimeo | Vimeo | Přehrávání vloženého video obsahu. | __cf_bm, _cfuvid, vuid, localStorage, IndexedDB | Relace až 2 roky |
| Facebook Login | Meta | Přihlášení pomocí účtu třetí strany. | Úložiště řízené poskytovatelem | Relace až 1 rok |
| GoPay | GoPay | Zpracování uživatelem vyžádané platby. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele |
Pomáhají nám porozumět používání webu a zlepšovat ho.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| Google Analytics 4 | Měření návštěvnosti a používání webu. | _ga, _ga_* | Až 2 roky | |
| Microsoft Clarity | Microsoft | Měření návštěvnosti a používání webu. | _clck, _clsk, _cltk | Relace až 1 rok |
Slouží k měření kampaní, personalizaci reklamy a marketingové komunikaci.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| Google Ads | Měření kampaní, reklama a remarketing. | _gcl_au, _gcl_ls | Relace až 90 dní | |
| Meta Pixel | Meta | Měření kampaní, reklama a remarketing. | _fbp, _fbc, localStorage | Až 90 dní |
| Sklik | Seznam.cz | Měření kampaní, reklama a remarketing. | retargeting, sid, szn:* | Relace až trvalé úložiště |
| LinkedIn Insight | Měření kampaní, reklama a remarketing. | bcookie, li_gc, lidc, __cf_bm | Relace až 1 rok | |
| Ecomail | Ecomail.cz | Měření kampaní, reklama a remarketing. | ecmid, Úložiště řízené poskytovatelem | Dle podmínek poskytovatele |
| Atribuce kampaní ITnetwork | ITnetwork | Přiřazení návštěvy a objednávky ke kampani. | campaign_clid[*], user_session_context | Až 1 rok |
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.
Četl jsi místní E-shop v ASP.NET? Tam se používá tuším AutoMapper.
Nad něčem podobném jsem přemýšlel, ale nějak nevidím výhodu v tom, 1:1 překlápět Entity třídy na ViewModel. V čem je výhoda?
Podstatou ViewModelu je IMHO to, že to není plnohodnotná entita, ale co nejmenší pomocná třída. I když mi to přijde také podivné, podle Best practices se to tak dělá. Výhodou je, že ViewModel nemusí kopírovat rozhraní entity.
Na AutoMapper se vykašli. Na začátku jsem ho měl rád a usnadnil ti práci, jakmile ale pak něco zrefaktoruješ, tak už ti to přestane mapovat property a musíš to stejně setupovat sám (a dost blbě se to debuguje ...). Jakmile pak máš nějaké vnořené mapování, tak to taky není žádná sláva, osobně jsem si zvykl pro mapování z objektu -> objekt (třeba Model na DTO, Model na ViewModel ... záleží jak si to pojmenuješ) napsat metodu sám.
Výhodu poznáš jakmile nebudeš dělat základní CRUD, ale budeš mít komplexnější scénáře. Tyhle otázky by ti měla objasnit třívrstvá architektura.
Osobně dělám POCO na každé vrstvě zvlášť a snažím se si nepřenášet závislosti tam kde nemusím. Na fakt jednoduchých věcech je to asi jedno, ale jakmile děláš něco většího, tak tě to při každé další změně potrestá.
Buďto je tu poslouchej a uděláš anemický model, kde absolutně nemáš žádný doménový model (to je právě to POCO - tam je na každé vrstvě jedna přepravka, mapuje se to mezi sebou a samotná logika je v přepravkách - je to více ale imperativní programování než objektové)... nebo je neposlouchej, udělej plný doménový model, ale pak se vykašli na věci jako UOW a repository, protože něco takového nemůže dohromady fungovat...
Mluvím o tom částečně i zde:
https://www.youtube.com/watch?…
Nesnažte se bože za každou cenu skloubit dva absolutně opačné přístupy, stejně vam z toho vyjde jen kočkopes.
Samotný EF není ani pro plný OOP přístup a rich domain model stavěný...více zde:
https://blog.inf.ed.ac.uk/…olid-design/
https://vaughnvernon.co/?…
A HLAVNE!!!!:
https://lostechies.com/…k-scorecard/
pardon oprava textu (toto forum z nejakeho nadpozemskeho duvodu nedovoluje editovat, takže mi nezbývá než spamovat). "Samotná logika je v servisách" u anemického modelu.
Marian Benčat Jan Vargovský díky za odpovědi. Asi se mám co učit. Jde o to, že tu máme větší projekt, který se rozšiřoval bez nějaké "architektury" a momentálně to dost hoří a celé se to sype -> bude se to přepisovat. Proto máme volné ruce a možnost to celé nastavit nějak rozumně. Chceme to udržet tak jednoduché jak jen to půjde, ale nějak rozumně navrhnuté.
Jedná se o WPF aplikaci, potřeba jsou typické úkony a práce s daty z
databáze.
Pokud máte jště nějaké tipy co nastudovat kolem toho, budu rád. Díky.
... samotná logika je v přepravkách ...
O tom ale přece nikdo nemluvil 
když řeknu DTO jako POCO, tak tam do toho neseru přece žádnou
logiku 
od toho mám tu
vrstvu nebo další servisy.
A četl si co jsem napsal hned pod tím??
"pardon oprava textu (toto forum z nejakeho nadpozemskeho duvodu nedovoluje
editovat, takže mi nezbývá než spamovat). "Samotná logika je v servisách"
u anemického modelu."
Nečetl obviously ... Máš nějaké příklady toho anemického modelu? Nějak nevidím co je blbě na tom, že máš logiku vyseparovanou někde jinde a pro přepravu dat mezi vrstvy používáš DTO.
je to v tom jednom odkazu.. v zásadě na anemickém modelu není špatně nic,.. ale není to OOP a stím jsou spojené jeho nevýhody i výhody.
Popravde se do teto debaty nechci poustet, protoze 1) toto je strašné forum a nechci každý debilní přepis řešit pomocí 10 dalších příspěvků... 2) je to tak na 2 hodky to probrat u piva
Zobrazeno 14 zpráv z 14.