Správičky 2 817 Blogy 948 Fórum 18 712

Prehľad diskusie

photo
Spigi
Liero
10. 5. 2018 17:02:55
photo
RE: Spigi
siro
12. 5. 2018 13:29:55
photo
RE: Spigi
T
18. 5. 2018 9:26:10
photo
RE: Spigi
liero
18. 5. 2018 10:43:42
photo
RE: Spigi
liero
29. 8. 2018 13:47:56
photo
RE: Spigi
.
30. 8. 2018 1:20:51
photo
RE: Spigi
liero
30. 8. 2018 17:09:56
photo
RE: Spigi
siro
30. 8. 2018 20:00:18
photo
RE: Spigi
.
30. 8. 2018 21:21:17
photo
RE: Spigi
liero
4. 9. 2018 13:09:17
photo
RE: Spigi
vlko
5. 9. 2018 9:42:18
photo
RE: Spigi
Liero
10. 9. 2018 9:29:35
photo
RE: Spigi
spigi
10. 9. 2018 9:56:09
photo
RE: Spigi
Liero
10. 9. 2018 12:05:15
photo
RE: Spigi
Liero
11. 9. 2018 13:35:01
photo
RE: Spigi
spigi
11. 9. 2018 18:41:50
photo
RE: Spigi
T
11. 9. 2018 22:22:28
photo
RE: Spigi
vlko
11. 9. 2018 23:15:32
photo
RE: Spigi
T
12. 9. 2018 8:29:08
photo
RE: Spigi
Liero
12. 9. 2018 11:38:42
photo
RE: Spigi
Liero
12. 9. 2018 13:32:39
photo
RE: Spigi
T
12. 9. 2018 20:29:49
photo
RE: Spigi
Liero
13. 9. 2018 9:26:24
photo
RE: Spigi
Liero
13. 9. 2018 9:44:57
photo
RE: Spigi
T
13. 9. 2018 12:25:42
photo
RE: Spigi
Liero
13. 9. 2018 14:19:15
photo
RE: Spigi
T
13. 9. 2018 20:56:11
photo
RE: Spigi
Liero
14. 9. 2018 9:32:32
photo
RE: Spigi
T
14. 9. 2018 18:35:44
photo
RE: Spigi
siro
16. 9. 2018 9:04:50
photo
RE: Spigi
Liero
16. 9. 2018 10:16:08
photo
RE: Spigi
T
16. 9. 2018 13:37:31
photo
RE: Spigi
Liero
16. 9. 2018 17:50:39
photo
RE: Spigi
T
16. 9. 2018 20:37:32
photo
RE: Spigi
Liero
17. 9. 2018 9:13:10
photo
RE: Spigi
T
17. 9. 2018 11:57:08
photo
RE: Spigi
Liero
18. 9. 2018 10:23:28
photo
RE: Spigi
Liero
18. 9. 2018 10:39:30
photo
RE: Spigi
T
18. 9. 2018 16:31:26
photo
RE: Spigi
Liero
19. 9. 2018 9:55:23
photo
RE: Spigi
Liero
19. 9. 2018 10:13:02

Spigi

photo
Liero
10. 5. 2018 17:02:55
Body: 9705
Najaktívnejší č.: 6

Spigi

Pls, Poviete niekto, @Spigimu, nech to tu administruje, alebo nech odovzda kluce od miesacky niekomu, kto to moze robit?

Ja som uz davno od neho pytal pristup k DB aby som mohol zmigrovat vyvojari.sk na novu verziu, ale neodpovedal

[Reakcia]

photo
siro
12. 5. 2018 13:29:55
Body: 6920
Najaktívnejší č.: 7

RE: Spigi

Na Facebook mu napíš...

Š#iro

[Reakcia]

photo
T
18. 5. 2018 9:26:10
Body: 21495
Najaktívnejší č.: 2

RE: Spigi

@liero: a nechcel si to prekodovat povodne ;-) (ze doniest miesacku a len si vypytat povolenie napojit sa na elektro?) :-D

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
liero
18. 5. 2018 10:43:42
Body: 9705
Najaktívnejší č.: 6

RE: Spigi

No ved ja to uz mam viac-menej prekodovane. Chcem zmigrovat data.

[Reakcia]

photo
liero
29. 8. 2018 13:47:56
Body: 9705
Najaktívnejší č.: 6

RE: Spigi

nemate na neho niekto cislo? Uz ma vazne hneva

[Reakcia]

photo
.
30. 8. 2018 1:20:51
Body: 2760
Najaktívnejší č.: 14

RE: Spigi

@liero: Mail nestaci?

i.stanek at chastia.com

 

[Reakcia]

photo
liero
30. 8. 2018 17:09:56
Body: 9705
Najaktívnejší č.: 6

RE: Spigi

Tam som mu pisal, neodpisuje

[Reakcia]

photo
siro
30. 8. 2018 20:00:18
Body: 6920
Najaktívnejší č.: 7

RE: Spigi

Možno by bolo dobré mu napísať cez FB....

Š#iro

[Reakcia]

photo
.
30. 8. 2018 21:21:17
Body: 2760
Najaktívnejší č.: 14

RE: Spigi

Pripadne skus nejaky z kontaktov http://chastia.com/Company/Contact.aspx (sekretariat, tel. podpora) - ak sa uz nedostanes po priamy kontakt tak mu aspon mozes nechat kontakt.

 

[Reakcia]

photo
liero
4. 9. 2018 13:09:17
Body: 9705
Najaktívnejší č.: 6

RE: Spigi

@Siro: tak mu skus napisat na FB, mne neodpisuje.

 

(.): jaj mam na neho email, kde som v minulosti s nim komunikoval, ked bolo treba nieco porobit na tomto portali, ale neodpisuje

[Reakcia]

photo
vlko
5. 9. 2018 9:42:18
Body: 37800
Najaktívnejší č.: 1

RE: Spigi

By som si tipol, ze je na dovolenke. pockaj este tyzden.

[Reakcia]

photo
Liero
10. 9. 2018 9:29:35
Body: 9705
Najaktívnejší č.: 6

RE: Spigi

@vlko:

nenasiel by si v starych maloch pristup na testovaciu databazu? Teraz mam chvilu casu doklepnut ten novy portal...

[Reakcia]

photo
spigi
10. 9. 2018 9:56:09
Body: 15965
Najaktívnejší č.: 3

RE: Spigi

Ahojte, 

liero, pozabudol som odpovedat na maily. Ako pisal vlko, najprv dovolenka, potom velmi busy.

Pred tym, nez cokolvek budeme kdekolvek presuvat, skusme si tu rozdebatovat, co chceme, ako to ma vyzerat, kto sa bude o to starat, kde je zaruka, ze sa starat bude apod. 

Tiez tie udaje v databaze mozme niekde zmigrovat, ale rad by som vedel kde. Co a kto teda konkretne chysta? Ako to vyzera?

Mozeme dat k tomu aj nejake pivko v BA a rozobrat to osobne. Kazdy tyzden som v BA aspon 1-2 dni. Liero, si lokalita BA? Vlko, Ty sa kedy vyskytujes v BA?

Dik. 

s.

PS: Na toto vlakno som si spravil v Outlooku pravidlo, aby som videl odpovede. Tak prosim pisme tu. Emailov mam denne niekolko desiatok, tak aby nezapadlo. 

Ing. Igor Stanek
CEO, Software Architect - CHASTIA s.r.o.
---
Chceš blogovať na tomto webe? Mať blog s adresou http://blog.vyvojari.sk/TVOJNICK?
Ozvi sa mi a tento blog Ti vytvorím.

[Reakcia]

photo
Liero
10. 9. 2018 12:05:15
Body: 9705
Najaktívnejší č.: 6

RE: Spigi

@Spigi: Vdaka za odpoved.

Takze postupne:

  1. co chceme:
    novsi design, podpora smartphonov, ochrana proti spamu, editacia prispevkov

  2. ako to ma vyzerathttps://vyvojari-sk-test.azurewebsites.net/ - je to starsia verzia, ale design tam je. MVP v podstate to kopiruje dnesnu funkcionalitu. Chyba este vyhladavanie a notifikacie.
  3. kto sa bude o to starat, kde je zaruka, ze sa starat bude apod.
    Kludne aj ty ak chces. Inak ja. Je to open source na githube, takze ktokolvek moze prispiet

  4. mozeme zmigrovat, ale rad by som vedel kde.:zatial chcem len napisat migracne skripty, takze len lokalne. Kludne aj anonymizovana databaza, ide mi hlavne o schemu. Inak by to malo bezat v Azure Database (PaaS), ak sa mi podari vybavit sponszorovany subscription.

Ja som v BA stale, nemam problem.

[Reakcia]

photo
Liero
11. 9. 2018 13:35:01
Body: 9705
Najaktívnejší č.: 6

RE: Spigi

Inak cudujem sa tvojej starosti o to, kto to tu bude spravovat, kedze zjavne teraz to tu nikto nespravuje. Mozno s vynimkou umiestnovania reklamy

[Reakcia]

photo
spigi
11. 9. 2018 18:41:50
Body: 15965
Najaktívnejší č.: 3

RE: Spigi

Ahoj, 

 

1. OK, chapem

2. OK, chapem. Problem vidim v migracii udajov - najma loginov, blogov. Toto nie je vobec jednoduche. To je na osobne stretnutie. 

3. Moja starost o spravu je opodstatnena. To, ze nemam cas aktivne spravovat web je pravda, ale minimalne bezi uz 16 rokov a upozornujem - STALE BEZI je nieco, co nie je bezne. Uz tu bolo mnozstvo portalov, ktore napriek velkej snahe vykapali - spominam si napr. na debug.sk a pod.

To, ze su tu bugy, spam (to by sa dalo relativne rychlo vyriesit) je dane "vekom" kodu.

4. Migracia by v tomto pripade bola potreba. Ale predtym, ako komukolvek poskytnem udaje, chcem mat istotu, ze bude zabezpecena migracia - bez nutnosti zasahu uzivatelov, aby sa nadalej vedeli nalogovat a aby nebol vypadok. To je presne to tom "starani sa". Kde je garancia, ze napriek Tvojej, alebo kohokolvek aktualnej snahe, Ta ta snaha neprejde o pol roka. Cim nenegujem tuto snahu a som za nu rad :).

K migracii este. Pozor, su tu casti kodu z roku 2002 a .NET 1.0, takze aj DB schema je dost komplikovana a narocna na migraciu. Nehovoriac o tom, ze 80% DB je schema z produktu, ktory sa volal Community Server pred viac ako 10 rokmi a ktory som malicko ohol, aby to tu bezalo a existovali jednotne loginy pre blogy a samotny web. Tento produkt medzicasom zanikol. 

Takze navrhujem osobne stretko, ale vidim to tak cca o mesiac. Do konca septembra nemam sancu. 

Ing. Igor Stanek
CEO, Software Architect - CHASTIA s.r.o.
---
Chceš blogovať na tomto webe? Mať blog s adresou http://blog.vyvojari.sk/TVOJNICK?
Ozvi sa mi a tento blog Ti vytvorím.

[Reakcia]

photo
T
11. 9. 2018 22:22:28
Body: 21495
Najaktívnejší č.: 2

RE: Spigi

tiez len nazor

1. @liero: ciele su dobre, tieto v podstate naplnene, design aj ked som nevidel este s udajmi vyzera naozaj lepsie....ja by som ale jeden ciel pridal, a rovno poviem, ze ten naplneny nie je - lahka udrzatelnost a prispievanie ku kodu. Kod je sice pisany prehladne, ale ten event sourcing a "ponatie cqrs" tam vnasa len neporiadok a pre vacsinu ludi tipujem to bude showstopper, aby nieco dorobili. Uplne zbytocna aplikovanie a navyse v mnohych smeroch zle. Najmarkantnejsie....na jednej strane pracne oddelene C a Q  ale separacia C a M, ktora je dolezitejsia tam nie je(v action hanleroch sa generuju eventy...).  Co vobec nechapem napr. pouzitie membus, synchronizacia spracovania cez dobehnutie denormalizeru (co je uplne popretie zmyslu takto sepaorvat C a Q) , query model urobeny ako relacny.(keby bolo command model bez es a relacny, to by som este uplne chapal, ale query model, ktory plni nieco co sa vola "denormalizer" a ktory ma relacie je mimo moj vesmir chapania). ale to tu nechcem rozoberat. Super iniciativa, kopa energie a zabite snahou aplikovat nieco, co nemam nacvicene a nemam v tom uplne jasno a vobec sa na takyto projekt nehodi a vacsina z publika potencialnych prispievatelov sa v tom strati. Nechces to revertnut kym sa da?

2. @spigy, o tie blogy sa bojim aj ja a nie je mi jasne, ako sa to da premigrovat...myslim, ze nijako....posledne roky tam velmi hodnotny content nepribudal a ten stary je ...stary....a blogovat sa mi v hentom engine naozaj nechce...je to neskutocne pracne, skarede...cize toto by som kludne nechal zakonzervovane a zacal na bude 0.

3. @liero Neviem posudit uplnost implementacie, pozeral som to zbezne...@liero mas to uz 1:1?

4. @liero, ak to spustis na separatnej domene alebo "subdomene", ja sa kludne zapojim do nejakeho demo pouzivania. Ak urobis nejako lepsie/jednoduchsie blogy, kludne obcas niecim prispejem...podla mna mozes zacat aj bez migracie a myslim si, ze nas takych bude aj viac. Migracia je strata casu...mozno spravicky...mozno ale fakt len mozno fora...

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
vlko
11. 9. 2018 23:15:32
Body: 37800
Najaktívnejší č.: 1

RE: Spigi

Podla mna ak sa to ma niekde pohnut treba urobit tieto veci:
1. zmigrovat ucty teda login/overovaci algoritmus v_old
2. locknut stary portal na updaty a teda zachovat routovanie na vyvojari.sk/Forum, vyvojari.sk/News*, stare blogy zachovat na adrese blog.aspnet.sk
3. vytvorit novy portal tak aby linkoval na nove spravicky/blogy/forum
4. start from scratch, pripadne nejak spristupnit tie stare linky na novych strankach

Osobne mne cely nova verzia pride zbytocna, nahodil by som tu discourse + nejaky ghost na blogy. Tento portal ma ale iny problem, nie su ludia a to nijaky redesign/rewrite nevyriesi:)

[Reakcia]

photo
T
12. 9. 2018 8:29:08
Body: 21495
Najaktívnejší č.: 2

RE: Spigi

@vlko: aj takto to dava zmysel...

problem bol aj ten community server blog...mna osobne do silne odradzalo...a chcelo to vela sabazprenia nieco publikovat...zasadne to ale novy portal nezmeni...ale mozno ked bude vyzerat modernejsie, pritiahne nejakych ludi aby sem prispeli napr. do fora.

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
Liero
12. 9. 2018 11:38:42
Body: 9705
Najaktívnejší č.: 6

RE: Spigi

Sample Data:

kliknite na zalozku sample data a generate all events. Naplni to portal datami.
 

Blogy:

neplanujem pisat vlastnu blogovaciu platformu. Zatial sa daju vlozit iba odkazy na blog, cize myslienka je taka, ze stare blogy ostanu bezat tam kde su, pripadne mozem zvazit nejaku readonly migraciu.
Zvazujem aj moznost mat vyvojari.sk ako Identity Provider, takze na externych blogoch by sa dali pouzivat vyvojari.sk ucty, ale nema to u mna vysoku prioritu.

Uplnost implementacie:

Kym to pojde do produkcie, je tam este vela veci, napriklad spominany routing, treba aj optimalizovat CSS, obrazky, cache a podobne veci., ale teraz je to v stave, ze sa mi neoplati na tom dalej pracovat pristupu k starej verzii.
 

Co sa tyka ES:

nemam problem, aby to niekto prekodil a mozem poskytnut navod, ale ja mam ine priority. Je to len moj experiment, no daval som pozor na to, aby sa to dalo lahko zmenit.
 
Len vysvetlim sucasny stav:
  1. Chceli sme mat historiu, ktora je podla mna potrebna, ked chceme mat editaciu

  2. Ukladat eventy + pisat denormalizery je pre mna rovnako vela roboty ako ukladat do normalizovanej databazy + pisat db views, ktore by vytahovali aktualne data z historie. Napriklad taky db view "Posledna aktivita" by sa mohol riadne skomplikovat a riesenie by pravdepodobne bolo vytvorit novu tabulku "Posledna aktivita", cim sa ale poprie zmysel

  3. Keby to nebol ES, tak by to bol zrejme CRUD pisany v controlleroch a ziaden DDD. Nemalo zmysel to komplikovat nejakym domenovym modelom. Tento "pattern" sa tusim nazyva Historical CRUD. 

  4. Rovnako nema v tomto pripade zmysel mat asynchronne commandy - neprinieslo by to ziaden realny benefit.
    Mam rozrobeny este jeden refactorig, kde by controller pri POST necakal na denormalizer, ale queries by cakali ten svoj denormalizer.
    *  prekvapuje ma ze @T tvrdi, ze zmysel CQRS je v asynchronite C a Q. CQRS to umoznuje, ale nieje to v definicii ale nieje to podmienka a urcite nie zmysel, vid napr:  Nights March 2016 Martin Fowler - Event Sourcing - asynchrony

  5. Event schema je zvycajne jednoduchsia a citatelnejsia ako DB schema, specialne ked podmienkou je historia.
  6. Event Bus mi umoznuje napriklad velmi transparentne invalidovat nacachovane partial views, alebo inu cache.
    Priklad: Url k fotkam userov som pridal do cache, inak som mal N+1 queries. Cache jednoducho invalidujem attachnutim sa na AvatarChanged event, pripadne ju rovno updatnem v pamati. Podobne je to s cachovanim partial views ako "posledne prispevky vo fore", "posledna aktivita", pocet komentarov atd...

  7. Event driven architektura je celkom handy, ked treba implementovat veci, ako posielanie notifikacii, pocitanie bodov, ziskavanie nejakych achievementov, typu - editovat prispevok moze iba uzivatel, ktory ma urcity pocet bodov atd.
    Novy event handler do Command modelu alebo denormalizer do Query modelu a je to. Inak by tato logica zrejme skoncila vsetka v controlleroch, pripadne v nejakom transaction scripte.

  8. InMem bus je tam len preto, ze tam je zatial InMemory databaza. Je to len zalezitost konfiguracie, ktoru rozhodnem, ked budem vediet, kam to budem deployovat.
To len na vysvetlenie, preco to je tak ako to je, netvrdim, ze to tak musi byt. Je to najjednoduchsia mozna varianta Event Sourcingu (bez DDD a bez asynchronity), ktora naozaj nieje komplikovana v porovnani s tradicnym pristupom. V takomto jednoduchom prevedeni benefity vyvazili cenu. Kazdopadne toto je len zlomok celkoveho effortu.

[Reakcia]

photo
Liero
12. 9. 2018 13:32:39
Body: 9705
Najaktívnejší č.: 6

RE: Spigi

@Spigi:

ved ja som ten kod uz videl, cosi som tu aj robil, aj DB access som uz mal. Mozes mi spravit kopiu databazy, kludne zatial vymaz/anonymizuj userov a hesla nech sa do toho konecne mozem pustit. Cas mam teraz, nie o mesiac. Uz mam chut sa na to vykaslat

[Reakcia]

photo
T
12. 9. 2018 20:29:49
Body: 21495
Najaktívnejší č.: 2

RE: Spigi

pokracujem off topic, ale ok.

1. pri vybranych veciach a da sa to riesit klasicky versioningom v jednej tabulke, extra tabulke...ja neriesim auditovatelnost  ale len historiu a to len pre vybrane entity. Cize nariadit celoplosny postrek komarov kvoli dvom, co mas v spalni moze byt hlupe. 

2. Pri velmi jednoduchom projekte s jednoduchymi views, v tomto projekte je to skoro 1:1...posledna aktivita -> nic ci nebrani si logovat do separatnej tabulky a denormalizovat to, co je ucelne aj bez ES a denormalizerov. (toto je ale naozaj pekny UC pre domenove eventy a denormalizer...btw. domenove eventy nutne neznamanaju ze command model musi byt es)

3.DDD - principy DDD maju zmysel takmer vsade, domenovy model v zmysle old school DDD tu velky zmysel nema...nie je tu takmer ziadna business logika...

ale oddelenie aplikacnej logiky od prezentacnej, hoci jednoduchym transaction scriptom("services") aj na takomto projekte opodstatnenie ma (= oddelenie (M od VC))

, ovela ovela vacsie ako delenie C a Q...

4. asynchronne commandy zmysel nemaju pri takomto projekte, ale este menej nedava zmysel pouzitie architektury, ktora vychadzala prave z predpokladu ich nasadenia...a potom ich nezmyselne synchronizovat cez dobehnutie konkretneho denormalizeru. 

Este inak / ak volim nejaku architekturu, musim vediet zdovodnit jej ucelnost/vhodnost. Potrebou synchronnosti popieram ucelnost/vhodnost zvolenej architektury.

5. To je nezmysel. Komplexita a citatelnost je nutne komplementarna a specialne pri takomto projekte. Samozrejme zalezi, ako robis relacny model. A code first nie je rozhodne to najlepsie na manageovanie komplexneho relacneho modelu. (ak vychadzas z takehoto predpokladu)
Jedinou vynimkou je pripad, ak mam semistrukturovane udaje, ale tam sa pojem "model" straca zmysel ale to nie je tento pripad. Tu mam krasne strukturovane udaje bez akejkolvek variability.

6. Ano, to je jedno z peknych pouziti ale je otazne, ci je to najlepsia strategia cacheovania pri taktomto projete a ci ta komplexita, ktoru si tymto vniesol je primerana prinosu (nie je)

7a) Event driven != Event sourcing

7b) Denormalizovane to mozes ukladat aj pri primarne relacnom modely ak je to len nejaka marginalna cast riesenia. Ano v takomto pripade to skonci niekde v transaction scripte ale to same o sebe nie je nutne zle (skaredsie, horsie) pri tomto konkretnom projekte. Btw. z transation scriptu si mozem kludne fireovat domenove eventy a mat na ne zavesene denormalizery a mat command model releacny. Aj takyto variant implementacie CQRS existuje.(to len na okraj)

8) konfiguracie? cize len zmenis nieco v .config a zrazu tam bude nejaky bus ktory zarucuje bezstratovost? Ano chapem, ze sa to da prerobit a nebude to moc prace. Ale vidis, mas tam zbytocne technologicke issue, nevies kde to nasadis, nevies co bude k dispozicii, vies, ze to budes musiet prerobit...s cistou relacnou databazou by si mal o problem menej. 

2011 Rinat

https://abdullin.com/post/when-not-to-use-cqrs/ 2012

  • Strategy explains how to wage a war. DDD is one of the viable strategies in software war and it is particularly good in dividing and conquering complex domains.
  • Tactics deals with winning a battle (there could be a lot of these in a war). CQRS is a flexible software tactics that is particularly fit for the DDD strategy

Obviously, you can try to take CQRS patterns and apply mechanically to any system. Sometimes this might work and sometimes this might be as awkward as using SQL Stored Procedures for business logic. 

Don't use CQRS in your system, if you have more important things you can do first. 

Udi 2011 http://udidahan.com/2011/04/22/when-to-avoid-cqrs/

Martin 2011 https://martinfowler.com/bliki/CQRS.html

Despite these benefits, you should be very cautious about using CQRS. Many information systems fit well with the notion of an information base that is updated in the same way that it's read, adding CQRS to such a system can add significant complexity. I've certainly seen cases where it's made a significant drag on productivity, adding an unwarranted amount of risk to the project, even in the hands of a capable team. So while CQRS is a pattern that's good to have in the toolbox, beware that it is difficult to use well and you can easily chop off important bits if you mishandle it.

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
Liero
13. 9. 2018 9:26:24
Body: 9705
Najaktívnejší č.: 6

RE: Spigi

@T: pozri sa, ked ta to tak irituje, sprav si novy branch, navrhni tam databazu a sprav aspon jeden controller. Zvysok dorobim. 8) Pouzivam tam kniznicu Rebus, ktora ma adapter na prakticky kazdy message bus (Azure Service Bus, RabbitMQ, MSMQ, SQL....), cize je to jeden riadok kodu. 3) Principy DDD su tu vyjadrene domenovymi eventami, ktore predstavuju ubiquitous language. Transaction Script je trivialne dorobit ad hoc, len teraz v kontroleroch naozaj nieje ziadna ina logika, len savnutie jedneho eventu. Odabstrahovat toto inej vrstvy by malo aky zmysel? Ak v controlleroch bude viac logiky, samozrejme sa to dorobi. Lenze dalsia logika bude v EventHandleroch, ktore mozu teoreticky produkovat dalsie eventy typu: UserMentioned, BadgeReceived, NotificationSent... 4) Suhlasim, ze je nezmyselne mat async commandy, synchronizovane cez dobehnutie denormalizeru. Toto sa nepaci ani mne. Zial neskoro som zistil, ze Rebus nema ziadne API na synchrony messaging. Ale presne kvoli tomuto som to robil, aby som prisiel na taketo veci. No ono tam predsa len nejaky zmysel je. Ja totizto cakam iba na jeden denormalizer, ktory potrebujem na spravne zobrazenie vysledku (po redirekte). Nemusim napriklad cakat na ActivityDenormalizer, pripadne nasledny workflow (notifikacie, maily, bodovaci system...). Zo synchronnym messagingom by to bol trochu problem. 5) Takze, relacna databaza by v tomto pripade vyzerala ako tabulky Content+ContentTypes, pripadne komplikovanejsia verzia s ContentFields+FieldTypes. Ked sa pozriem na takuto schemu, tak nevidim nic. Cize ak by som to chcel spravit aspon trochu expresivne, tak budem musiet nejakych sposobom vyjadrit v kode to, co som vyjadril mojou eventovou schemou, ci uz pomocou Commadov, Transaction Scriptu etc.. Inak suhlasim skoro zo vsetkym, co si povedal, len (relacny model + verzie contentu v relacnom modely + denormalizovane tabulky + domenove eventy) mi nepride jednoduchsie ako ES.

[Reakcia]

photo
Liero
13. 9. 2018 9:44:57
Body: 9705
Najaktívnejší č.: 6

RE: Spigi

@T: pozri sa, ked ta to tak irituje, sprav si novy branch, navrhni tam databazu a sprav aspon jeden controller. Zvysok dorobim.

8) Pouzivam tam kniznicu Rebus, ktora ma adapter na prakticky kazdy message bus (Azure Service Bus, RabbitMQ, MSMQ, SQL....), cize je to jeden riadok kodu.

3) Principy DDD su tu vyjadrene domenovymi eventami, ktore predstavuju ubiquitous language. Transaction Script je trivialne dorobit ad hoc, len teraz v kontroleroch naozaj nieje ziadna ina logika, len savnutie jedneho eventu. Odabstrahovat toto inej vrstvy by malo aky zmysel?
Ak v controlleroch bude viac logiky, samozrejme sa to dorobi. Lenze dalsia logika bude v EventHandleroch, ktore mozu teoreticky produkovat dalsie eventy typu: UserMentioned, BadgeReceived, NotificationSent...

4) Suhlasim, ze je nezmyselne mat async commandy, synchronizovane cez dobehnutie denormalizeru. Toto sa nepaci ani mne a rad by som to zmenil. Zial neskoro som zistil, ze Rebus nema ziadne API na synchrony messaging. Ale presne kvoli tomuto som to robil, aby som prisiel na taketo veci.

No ono tam predsa len nejaky zmysel je. Ja totizto cakam iba na jeden denormalizer, ktory potrebujem na spravne zobrazenie vysledku (po redirekte). Nemusim napriklad cakat na ActivityDenormalizer, pripadne nasledny workflow (notifikacie, maily, bodovaci system...). Zo synchronnym messagingom by to bol trochu problem.

5) Takze, relacna databaza by v tomto pripade vyzerala ako tabulky Content+ContentTypes, pripadne komplikovanejsia verzia s ContentFields+FieldTypes. Ked sa pozriem na takuto schemu, tak nevidim nic.
Cize ak by som to chcel spravit aspon trochu expresivne, tak budem musiet nejakym sposobom vyjadrit v kode to, co som vyjadril mojou eventovou schemou, ci uz pomocou Commadov, Transaction Scriptu etc..

Inak suhlasim skoro zo vsetkym, co si povedal, len (relacny model + verzie contentu v relacnom modely + denormalizovane tabulky + domenove eventy) mi nepride jednoduchsie ako ES.

[Reakcia]

photo
T
13. 9. 2018 12:25:42
Body: 21495
Najaktívnejší č.: 2

RE: Spigi

irituje...neirituje ma nic, len som sa Ti snazil napisat, ze z hladiska toho, ze to ma byt nejaka komunitna platforma to zbytocne podriadil nejaku svojmu experimentorstvu(mal si si vybrat jeden ciel, nie dva, ktore si protirecia)...to je v podstate vsetko podstatne...nerozumiem, aky controller mam pisat...kludne dopisem, ak to bude nejaka normalna architektura a budem v tom vidiet zmysel

8. ok

3.  "Principy DDD su tu vyjadrene domenovymi eventami, ktore predstavuju ubiquitous language"

co ma ubiquitous language spolocne s domenovymi udalostami? Domenove udalosti by mali byt v zmysle DDD pomenovane v ubiquitous language (tak ako commandy, entity a metody domenoveho modelu). To je jedina zmysluplna veta/reakcia, ktora sa na to da napisat.

"len savnutie jedneho eventu."

Toto jednak nie je pravda(a nebude, ak to dotiahnes)...ale ja som hovoril o inom...ze separacia C a Q je menej podstatna ako M a VC a specialne v tomto projete. Takze ano, ak je tak jednoduchy, ze sa neoplati separacia M a VC, tak s najvacsou pravedpodobnostou o to menej C a Q.

"Lenze dalsia logika bude v EventHandleroch, ktore mozu teoreticky produkovat dalsie eventy typu: UserMentioned, BadgeReceived, NotificationSent..."

Moze, ak by to ako v tomto pripade nebola uplna marginalita, ktora sa da obkodit aj inak. Pouzit kanon na vrabce, zase nieco, v tom sa bezny clovek strati (chces to spristupnit davom, vsak?).

A to o com pises je skor nastroj na korelaciu a aggregaciu udalosti ako "event handler"....v nservicebus sa na to (obe veci) pouzivaju sagy (potrebujes mat spolocny kontexte a vediet spracovat nejaku postupnost eventov), event store ma dokonca jednoduchu CEP(complex event processing) engine, ktore sa na to standardne pouzivaju.

"Ja totizto cakam iba na jeden denormalizer, ktory potrebujem na spravne zobrazenie vysledku (po redirekte)."

Ved ja vidim, co robis. Na toto ta architektura nie je. Riesit sa to da tak, ze zobrazis po submite hlasku a user si pocka, kym sa to, co odoslal zobrazi.(napr.)

4.  Ale to nie je o synchronnom messagingu. To je o tom, ze mas zlu architekturu, ak si sam uvedomujes, ze ovela praktickejsi by bol v tomto pripade sync pristup. A spracovanie commandov (synchronne) vs. asynchronne spracovanie je jedna vec. Druha vec je eventualna konzistencia. Ty mas zjavne problem s tou druhou vecou, lebo commandy spracovavas synchronne.(controller) To je ale predpoklad pouzitia takejto architektury. Ked sa nechces vysporiadavat s EC, tak urob iny(vhodnejsi) design.

5. celej tejto uvahe nerozumiem. Relacny databazovy model pre vyvojari.sk by vyzeral pekne a prehladne. Rovnako by vyzeral aj model eventov. "Content+ContentTypes" to fakt netusim, aky model by si v relacnej databaze robil Ty.

6. Maximalna primerana forma cqrs pre takyto projekt je jedna shareovana databaza pre C a Q a query model postaveny bud nad viewmi alebo kludne aj Linq to EF lebo queries su trivialne.

Commenty su asi jedina vec, ktoru treba verzionovat. (mozno clanok, mozno blog post ale to asi ani nikto neocakava)...cize jedna z 50 entit/agregatov aj to je otazka, ci chcapat comment ako aggregat root. Takze v relacnom modely jedna tabulka s historiou....verzus cela ES/CQRS komplexnost.(navyse ak by som ju chcel mat vsade, tak si spravim jeden interceptor na urovni datoveho pristupu a ani neviem, ze taku historiu logujem)

 

 

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
Liero
13. 9. 2018 14:19:15
Body: 9705
Najaktívnejší č.: 6

RE: Spigi

Myslel som, ze mozes na nejakej casti portalu (napr spravicky) ukazat, ako by si to robil a ja potom podla toho prerobim zvysok. Mas ten luxus, ze funkcne je portal takmer hotovy, presne vies ako budu vyzerat views, atd...

Co sa tyka relacnej databazovej schemy (5), ked das kazdu entitu do osobitnej tabulky ako budes robit napr fulltextove vyhladavanie? Query na kazdu tabulku? Taketo CMSka zvycajne ukladaju vsetok content do jednej tabulky a nemaju klasicku relacnu databazu.

 

A nerozumiem tomuto: "" v controleroch je len savnutie jedneho eventu." - Toto jednak nie je pravda(a nebude, ak to dotiahnes):
Co nieje pravda? Co ine tam este robim? Ak tam nieco pribudne, tak sa tam dorobi to M, bud ako TS, alebo inak, ale v sucasnom stave neviem co ina ako ten SaveEvent sa da odtial vytiahnut.

 

"ze separacia C a Q je menej podstatna ako M a VC a specialne v tomto projete. Takze ano, ak je tak jednoduchy, ze sa neoplati separacia M a VC, tak s najvacsou pravedpodobnostou o to menej C a Q."

Tu si dovolim nesuhlasit. Kedze aspon zatial business logika ne skoro nulova, hodnota separovaneho M je tiez skoro nulova. Ale zo separacie C a Q benefitujem stale. Napriklad Eventy som si definoval uplne na zaciatku, hned potom aj ich vytvaranie v POST metodach controllera a odvtedy sa to prakticky nemenilo. No Query model menim stale, napriklad ked mi grafik dal grafiku a vlozil tam view "posledna aktivita", alebo teraz ked robim fulltextove vyhladavanie.

Kazda takato zmena by si bez CQRS vyziadala viac refactoringu aj v command aj v query casti. Takto prakticky menim iba query cast.

[Reakcia]

photo
T
13. 9. 2018 20:56:11
Body: 21495
Najaktívnejší č.: 2

RE: Spigi

@liero:

teraz ale fakt neviem, co mam/v akom style dorobit? S tranzaction scriptom a relacnym modelom, a symbolickym rozdelenim C a Q(db view a dva EF contexty)...alebo uplne bez neho? (dorabat do niecoho existujuceho je niekedy narocnejsie ako zacat od zaciatku ... a druha vec, nemas to zakladne, databazovy model) ...spravicky,fora,clanky,commentare,blogy

" Co ine tam este robim?"

napr. kontrolujes opravnenia, staticky aj kontextovo(asi nechceme aby som mohol jano jozovi editovat spravicku, vsak)? kontrolujes existenciu entity?(=riesis kontextove validacie, ktorych sa najde casom urcite viac? Nejake hlasky userovi o vysledku operacie? Nebude  riesit error handling na urovni spracovania commandov? (asi nebudes, naco to sofistikovane logovat a userovi dat moznost cez nejake IDcko reportovat chybu)...atd.

....Fulltext...existuje x technik ako intelignetne riesit fulltext...pouzitie externeho indexovacieho engine(ktory si uklada indexy niekde vonku)

...trivialny materializovany view s fulltext indexom (v ms sql tusim nejde union pri indexed views, takze si musis vybrat poriadnu db)...

...a ano, kludne aj specializovana tabulka pre indexovanie...jeden insert naviac pri par entitach...nevidim problem...rovnaky pocet riadkov kody ako ked pises denormalizer, akurat tu je krajsie, ze to mas pokope.

"hodnota separovaneho M je tiez skoro nulova. Ale zo separacie C a Q benefitujem stale. Napriklad Eventy som si definoval uplne na zaciatku, hned potom aj ich vytvaranie v POST metodach controllera a odvtedy sa to prakticky nemenilo."

v momente, kde to prestane byt prototyp pochopis, ze sa mylis, vid. vyssie veci, ktorymi sa nezaoberas a ktore Ti vnesu do tych kontrolerov komplexistu ....

"No Query model menim stale, napriklad ked mi grafik dal grafiku a vlozil tam view "posledna aktivita", alebo teraz ked robim fulltextove vyhladavanie."

...vies si view dorobit kedykolvek aj pri relacnom pristupe...nechas pregenerovat ef context a uz aj queryujes....a to bez nutnosti prehravat eventy, aby sa ti denormalizovali udaje a ladit denormalizer....ja robim default separaciu C a Q aj pri releacnom modely ale uplne jednoducho (jeden EF context commnad, druhy nad viewmi query), v tomto zmysle to povazujem za uzitocne aj na takto malom projekte, ale neviem, ci by som do toho isiel pri nejakom komunitnom vyvoji, ked to nebude vacsine ludi davat zmysel. Pochop uz, ze ta denormalizacia dava zmysel pri velkych skalovatelnych riesianiach, pri pouziti (noSQL) technologii, ktore z toho vedia profitovat, pri pouziti aync spracovania....atd. nie v pripade relacnej databazy...kde mas query model relacny...akoze nerelacny command model transformujes na relacny query...to si doteraz nevysvetlil preco...

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
Liero
14. 9. 2018 9:32:32
Body: 9705
Najaktívnejší č.: 6

RE: Spigi

Taka separacia C a Q ako ty popisujes je len iluzia nejakej separacie.

Vid priklad z vyhladavanim: podla tvojho navodu mam robit dalsi insert navyse, pripadne externy indexovaci system, pripadne vymenit MSSQL za Oracle alebo co. Vsetko toto vyzaduje dost zasadne zmeny v command casti, tak o akej separacii sa tu bavime?

Iny priklad: Pridanie latest activity viewu by podla tvojho navodu (nova tabulka) znamenalo zmeny prakticky do celej command casti. Tak aka separacia C a Q?

"takze si musis vybrat poriadnu db" - aha, takze pre to navrhovane "jednoduchsie" riesenie a vhodnejsie pre komunitny vyvoj nieje ani MS SQL dobry. To bude naozaj radost vyvijat v porovnani s tym co tam je teraz - netreba ziadnu DB, vsetko vie bezat InMemory, na spustenie a zbuildovanie staci .net core sdk.


"teraz ale fakt neviem, co mam/v akom style dorobit?".

V akom uznas za vhodne. V Controleroch mas ViewModely na vstupe aj vystupe, vyhodis CommandStack a QueryStack projekty a vytvoris si vlastny relacny model.

Akurat by som sa rad vyhol Databazovemu projektu vo Visual Studio, lebo to pridava zavislost na Visual Studio a Windows. Momentalne to funguje celkom dobre aj vo VS Code aj na Macu.

[Reakcia]

photo
T
14. 9. 2018 18:35:44
Body: 21495
Najaktívnejší č.: 2

RE: Spigi

"Taka separacia C a Q ako ty popisujes je len iluzia nejakej separacie. "

Naozaj? Mozno vo vztahu ku tvojej nespravnej predstave o CQRS. Tak si najpr zadefinujem pattern.

Command and Query Responsibility Segregation (CQRS) is a pattern that segregates the operations that read data (queries) from the operations that update data (commands) by using separate interfaces.

to je aplikacia patternu, ktora je primerana projektovym vychodiskam.(podla mna, mam to odskusane na n projektoch s podobnymi vychodiskami a roznymi technologiami) 
Vychodiska, ktore vnimam... (relacna db, bez ocakavania horizontalnej skalovatelnosti, komunitny vyvoj, zvacsa crudy, takmer ziadna business logika)....iluzia teda este v com? Ze mam dva modely/interfaces a pod nimi mam infrastrukturu ktora je efektivna voci tech. vychodiskam, ze aplikovanim tejto separacie na projekte ziskam (menej komplexnosti, produktivita)....nie stratim (vnesiem viac komplexnosti, zabijem produktivitu) ? Cielom CQRS je pomoct riesit problemy a formu musis prisposobit tomuto cielu...nie exhibicionizmu, ktory potom dopada vacsinou zle...(pattern vznikol pre riesenie komplexnych domen, kde aplikacia old school DDD pristupov pre implementaciu nefungovala, zabijala projekt komplexnostou, ktory vnasala a nereflektovala poziadavky na "big") 

ano, toto je presne taky sposob myslenia, ktory nikto pri CQRS vidiet nechce/nechcel. Naozaj treba aplikovat najkomplexnejsiu jej formu, aj ked z nej nemas ako profitovat, pouzijes technologie, ktore na nu tuto formu ani nie su vhodne, neovladas jej podstatne detaily, nemas na to projekt a dokonca ju ani nechces.(lebo eventualna konzistencia je pre Teba nieco nezelane podla kodu)...keby si si zo vsetkeho co som nalinikoval precital aspon ten Fowlerov clanok...krajsie ten zdvihnuty prst (kedy ano a kedy nie) ja nepopisem...Nie je lepsie zacat niecim jednoduchym a primeranym? ...a popritom citat...vela citat a premyslat?

"Vid priklad z vyhladavanim: podla tvojho navodu mam robit dalsi insert navyse, pripadne externy indexovaci system, pripadne vymenit MSSQL za Oracle alebo co. Vsetko toto vyzaduje dost zasadne zmeny v command casti, tak o akej separacii sa tu bavime?"

sorry, toto nema hlavu ani patu....NIKDY nebolo ambiciou CQRS vyriesit vsetky problemy ...to ziaden pattern nedokaze...riesi/pomaha riesit konkretny problem...a konkretne aky sa docitas na linkach...(komplexna domena...poziadavky na skalovatelnost)...jedna metoda, ktoru volam zo vsetkych miest, kde potrebujem nieco zaradit do toho centralizovaneho fulltext vyhladavania? To je fakt problem, ktorym obhajis zmysel volby zlej architektury. Mimochodom, je uplne bezne...ze fulltext riesis externou technologiou pri CQRS...je to uplne iny problem ako C a Q.(elastic, solr...)...jedina vynimka su db, ktore su postavene nad takymto engineom a maju fulltext implicitne k dispozicii (ravendb)....este inak C a Q a F su tri problemy a zvacsa sa ich oplati (na komplexnom projekte) riesit separatne. Tento je malinky, tak som Ti napisal, co povazujem za najefektivnejsiu formu.(pekne sa da vyrobit fulltext builder, ktory bude mat genericku metodu per entita napr. a bude zodpovedat za budovanie takejto ftabulky pre fulltext indexaciu a bude to rovnako pekne ako denormalizer...on to vlastne denormalizer je)

btw. insert naviac je nieco apriory zle? Taky isty insert ako robis Ty v denormalizeroch? Vlastne ty robis tych insertov viac, lebo si sa mne stale z neznameho dovodu rozhodol pre relacny query model ;-)

a tu sa odusevnujes nad tym, ze som Ti navrhol pouzitie inej databazy s nejakou mudrou vlastnostou (a nie, oracle som pri comunitnom vyvoji pred ocami nozaj nemal)....a Ty znasilnujes relacnu db na storovanie niecoho na co su ovela efektivnejsie no sql databazy a este si nedas ani tu namahu, aby si par nastaveniami ukladal udaje tak, aby si aspon trochu zmiernil limitacie(vypolo lockovanie napr. pri inserte)...pre komunitny vyvoj pouzijes drahu DB, ktora je aj vo verzi STD mrzakom, hoci mas niekolko free alternativ.

"V akom uznas za vhodne."

cize si to mozes nakodovat sam...okrem viewov nemam v podstate nic....tak? A viewmodely som nepozeral, ako si ich urobil. Videl som, ze query data lopatujes z controllerov.

Dabazovy projekt bol nahodou super, VS community je zadarmo, dokonca mame nieco podobne aj pre ine databazy....ale splnit tuto poziadavku by bolo najmenej....

ved sa kludne u nas zastav niekedy, ked bude klud a mozeme si prejst ako robime architekturu pre taketo projekty...to je asi najefektivnejsia forma...

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
siro
16. 9. 2018 9:04:50
Body: 6920
Najaktívnejší č.: 7

RE: Spigi

Nie je to zlé, keby sa trošku modifikoval dizajn (hlavne ten header, ostatok je v pohode), tak podľa mňa by to bolo dobré. Oceňujem, že @Liero sa do toho vôbec pustil a že to vôbec dokončil do ako tak finálneho stavu. Neveril som mu a osobne si myslím, že by sa to malo nejakým spôsobom použiť a pracovať na tom ďalej. @Liero nehádal by som sa s @T, lebo on sa bude s tebou hádať stále, on to má už roky rokúce v povahe. Kiež by ti radšej miesto písania pomohol alebo urobil niečo zmysluplné. Dôležitý je výsledok a ten ako som povedal, nie je vôbec zlý.

@Spigi osobne si myslím, že toto môže pomôcť aj tebe ako majiteľovi domény, pracujem už pomaly na konferencii CodeCon 2019 a ak bude nová verzia funkčná do konca tohto roka, tak tam budem túto stránku veľmi propagovať, pretože si myslím, že toto potenciál má. Ak to nenaučíme mladých ľudí, tak táto stránka bude už nenávratne stratená.

MIGRÁCIA DÁT:

Ja by som si s tým hlavu nelámal a urobil by som úplne novú DB. Starý content by som poslal na večný odpočinok aj so starými blogmi. Staré nikoho nezaujíma a verím, že aj návštevnosť poriadne klesla kvôli contentu. Veci čo boli "in" sú už dávno "out" a ak sa budeme držať starého ducha, tak nič sa nezmení.

@Liero v každom prípade dobrá práca!

Š#iro

[Reakcia]

photo
Liero
16. 9. 2018 10:16:08
Body: 9705
Najaktívnejší č.: 6

RE: Spigi

@Siro: "lebo @T sa bude s tebou hádať stále, on to má už roky rokúce v povahe"

ved to aj ja :) ale konfrontovat svoje nazory s inymi je vzdy uzitocne.

"keby sa trošku modifikoval dizajn, hlavne ten header" - povodne tam bol modry, podobalo sa to na stackoverflow, ale ja som chcel, aby to malo nejaku spojitost so sucasnymi vyvojarmi.

 

@T: cize si to mozes nakodovat sam.

Presne tak. Neviem preco ocakavas, ze vsetko budem robit ja... Ja uznavam ze Event Sourcing je v tomto pripade kanon na vrabce, ale funguje to celkom dobre a nevidim ziadnu pridanu hodnotu v tom ze to budem prerabat na nieco ine a uz obzvlast nie, ak by to malo zvysovat naroky na dev prostredie. No zaroven nikomu nebranim, aby to prerobil.

To ze tam nieje Mko a ze query lopatujem v controleri len ulahcuje robotu tomu, kto to bude chciet prerobit.

 

 

 

 

[Reakcia]

photo
T
16. 9. 2018 13:37:31
Body: 21495
Najaktívnejší č.: 2

RE: Spigi

@siro: cisty offtopic a podpasovka...klasika...diskutovat (upozornit na nejaky problem) je nieco ine ako hadat sa. To je mozno Tvoja rovina uvazovania...aby som neoplacal malicherne, tak nenapisem ze roky...prist s niecim "genialnym" a nebyt schopny prijat konstruktivnu kritiku alebo iny nazor a reagovat jesitne ..ale dost sa cudujem, ze este po rokoch sa nevies zmierit s tym, ze na Tvojej ceste za "uznanim"(to bolo vzdy citatelne) Ti niekto napisal aj nieco(nebol som jediny, ze), co sa Ti nepacilo a nevedel si prijat a dodnes mu to zjavne nevies odpustit ...zdrhol si odtialto, pouzival si vyvojari.sk akurat na promo a linkovanie, zalozil si si svoj blog a postupne som Ti tam prestal chodit priznit blogy, kde je problem?....

mimochodom, ja som napisal aj pozitivne veci smerom k @lierovi...(a vzdy aj na margo Tvojich aktivit ak som ich videl)

..a pises, ze vysledok? Aktualne je to funckny prototyp(nemyslim to v zlom)...vysledok bude....niekolko rokov udrziavana stranka(ako pisal @spigy) a ak ma do nej prispievat nejaka skupina ludi(to bol deklarovany zamer, ktory sa mi paci), tak by to nemalo byt nieco architekturne "zle alebo komplikovane"...ta investovana energia mohla byt investovana lepsie (vo vztahu ku komunite)..to bolo vsetko podstatne, co som chcel napisat...zvysok diskusie je venovany CQRS...(o ktorom som uz diskutoval s Lierom v case zameru, ale nedal si poradit, teraz hodnotim " medzi" vysledok)...

@liero: ja nic neocakavam, okrem blogov viem zit aj s tym, co tu je. Bola to Tvoja iniciativa, ja som ju podporoval a podporujem. Krizitoval som a) nenaplnenie pre mna podstatneho ciela, aby mohli prispievat kodom dalsi ludia - zamer sa mi pacil ale nie vysledok a napisal som preco b) formu CQRS - cisto architekturna zalezitost a pokracovanie starsich diskusii, ked uz si sa napriek varovaniu o nevhnodnosti specialne ES pri tomto projektovom setupe na to podujal

liero "prerobit" = v tomto pripade nanovo nakodovat...hodit 80% Tvojej namahy do kosa. Pre mna by to bola cista rutina, mam ovela zaujimavejsie veci v stacku, ktorym sa potrebujem venovat. A urcite neurobim to, ze to postavim na hypergalaktickych technologiach, aby som si to vyskusal a malo to pre mna pridanu hodnotu. Vysledok neisty a aj keby bol dobry, pre vacsomu ludi neuchopitelny, mimo mainstream, ktory by mohol prispiet.

Prave naopak...bolo by nadherne ukazat bezpecnu architekturu, pattern pre takyto typ aplikacie...v asp.net mvc core...to by same o sebe okrem novej platformy dalo zacinajucim ludim dalsiu pridanu hodnotu...(ale zle aplikovane cqrs je presnym opakom)

 

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
Liero
16. 9. 2018 17:50:39
Body: 9705
Najaktívnejší č.: 6

RE: Spigi

80÷ mojej namahy urcite nebolo ukladanie a queryovanie dat,to skor tych 20÷. Ked to nechces zahodit do kosa, tak preco ma presviedcas, aby som to prekodil ja? :) Nemyslim si, ze ten EventSourcing je realne nejaky bloker. Naopak, teraz je to super easy skompilovat a spustit Netreba ani deployovat databazu, ani nic instalovat, dokonca netreba ani visual studio, takze je to maximalne jednoduche. Tiez nechapem, ak je jednoduchost vyvoja cielom,preco ma kritizujes,ze som nepouzil NoSQL databazu. Nuz lebo by ju bolo treba instalovat, pravdepodobne by sa nedal pouzit EntityFramework,ktory kazdy pozna a ma InMemory provider. Nic by som tym neziskal a vyrazne by som stazil niekomu zacat prispievat

[Reakcia]

photo
T
16. 9. 2018 20:37:32
Body: 21495
Najaktívnejší č.: 2

RE: Spigi

@liero: Ja Ta nepresviedcam, aby si to preprogramoval.(citaj pls). Ja len pisem, ze keby som sa do toho mal pustit ja(s tym si sa na mna obratil Ty), tak mi zostava 20% pouzitelneho kodu.(views - nemam db model, nemma queries voci relacnemu modelu, nemam tran script, controllery a view model musim prerobit)

Blocker(kde som to vrdil?) nie, zbytocna komplikacia/odradzujuci prvok ano. Jednoduchost - to iste by si dosiahol s ovela mensim poctom komponentov aj pri "klasickom" pristupe.(core + ef + ms sql...ale mozno radsej postgre...)

NoSQL - zase mimo, ja som hovoril o tom(citaj pls), ze ked si sa uz rozhodol pre CQRS preco si nepouzil NoSQL, ktora je prirodzenejsia, tu si znasilnoval MS SQL a znasilnil si ho navyse nedobre. (resp. preco si rovno nepouzil nieco na ES site napr. event store, ktory ma v sebe celu potrebu infra na C aj Q a je na toto naozaj efektivny...)

"pravdepodobne by sa nedal pouzit EntityFramework,ktory kazdy pozna a ma InMemory provider"

sorry, ale toto je zase cele take zbytocne zbrkle....a neverim, ze by si na to neprisiel aj sam....

1. A naco Ti je pri NoSQL databaze a specialne pri CQRS s ES...objekto-relacny mapper? (ak si odmyslim to uplne nezmyselne vnesenie relacneho modelu do Q casti)
nanic...nemas problem relacie v ramci agregatov, ukladas ich cele....a pouzivas z toho, co najdes v ORM len uplne okrajovu cast funcnosti...presne tu, ktoru ma v sebe napr. .... RavenDB klient (moznost queryovat cez linq, CRUD, schopnost serializovat objekt a ulozit, unit of work...)...

2. Napr. RavenDB.....EmbeddableDocumentStore { RunInMemory = true } 

3. Cast no sql databaz netreba instalovat...rovno je alebo vie to bezat ako nejake .exe, installer je zvacsa kvoly toolingu....alebo behu ako windows service

4. OK este pre istotu spat k ORM, problem relacii existujuce v no sql svete....vazby medzi agratmi...ale aj na to ma vacsina nosql slusnu podporu v ramci klientov....

P.S. a este raz k tej otazke EF....Tebe je vlastne naco EF v tomto projekte? V C casti uplne nanic, co z neho vyuzivas? V Q casti ak by si hodil do kosa ten ralacny model tak najvacsiu pridanu hodnotu ma linq provider....myslim sa?

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
Liero
17. 9. 2018 9:13:10
Body: 9705
Najaktívnejší č.: 6

RE: Spigi

Ach jaj, ty popries aj vlastnu matku aby vyhral argument.

"Ja Ta nepresviedcam, aby si to preprogramoval.(citaj pls)" Naozaj? Prvy komentar si ukoncil: "Nechces to revertnut kym sa da?" O com sa ty cely cas bavime potom?

"Blocker(kde som to vrdil?)" - Ked uz si nepamatas, co pises, tak aspon citaj po sebe: "pre vacsinu ludi tipujem to bude showstopper"

Ak tvrdis, ze by si musel zahodit 80% projektu, alebo zahodit 80% namahy, tak mam pochybnost ci vobes vies, co full stack development obnasa. Pre istotu citujem, keby si sa to zasa snazil popriet: "hodit 80% Tvojej namahy do kosa."

Mas to tam tak naservirovane, ze pohodlnejsie to uz ani nemoze byt.

  • Transaction Script tam ziaden nieje, takze nemas co zahodit.
  • ViewModel nemas preco prepisovat. Ak som tam aj pouzil DTO z querymodelu (nepamatam), tak by si to mal reusovat a namapovat 1:1 na DB View.
  • Mas presne definovane co maju DB views vracat
  • Mas presne definovane, co je na vstupe commandov
  • Ked budes mat views a transaction script, refactoring controllerov je tiez trivialny. Okrem toho, ziadal som ta iba o jeden controller

"Tebe je vlastne naco EF v tomto projekte" - pretoze sa mi neche pisat RAW sql commandy, nechcem zatial byt zavysli na kontretnej DB, lahko sa to deployuje, lahko sa to mockuje v testoch a vie to bezat inmemory aj bez DB enginu.

Anyway, uz som z tejto diskusie unaveny, takze ak nemas v umysle urobit nejaky contribution, ani sa neunuvaj odpispovanim

[Reakcia]

photo
T
17. 9. 2018 11:57:08
Body: 21495
Najaktívnejší č.: 2

RE: Spigi

@liero: naozaj si detinsky teraz vypisujme, koho to viac unavuje a vacsinu energie venujes ad hominem, popritom neodpovedas na otazky, preskajues argumenty na ktore nemas odpoved, ohybas vyznamy...

Pisal som, ze vacsinu ludi, nie vsetkych (o com som presvedceny a keby si nachvilu mal dovod sa na veci pozriet z nadhladu a nie z tej pozicie, ze som to napisal ja) tak by si to uznal. A blocker pri prispievanie to nie je. To ma uplne iny vyznam / pre mna.(ze nemozu, nedokazu)

"tak mam pochybnost ci vobes vies, co full stack development obnasa."

:-) keby som nevedel, tak nepisem, ze 80%.

1. "Transaction Script tam ziaden nieje, takze nemas co zahodit."

fakt k veci, kedze sa bavime o tom, co sa da z existujuceho kodu pouzit, resp. kolko treba zahodit

2. ViewModel nemas preco prepisovat.

mam a hned niekolko....ale ten by MOHOL, keby som sa chcel podriat niecomu so sice nie je najkrasie, ale "robi sa to tak" z vacsej casti zostat, zaroven je v nom vsak minimum kodu.(je triavialny)

3. Mas presne definovane co maju DB views vracat

zase mimo, bavime sa o kode, ktory, treba hodit do kosa...nie analytickom poznani...ktore je navyse pri tomto projekte uplne trivialne (mam predsa funkcnu predlohu a vidim, co musim vracat)

4. Mas presne definovane, co je na vstupe commandov

a dalsi mimo, vid. bod predtym, toto argumentujes v prospech reusenutia nejakej casti kodu?

5. Ked budes mat views a transaction script, refactoring controllerov je tiez trivialny

Zase mimo...pomohol si si slovom refactoring....ale je to prepisanie vacsiny kodu v controlleroch...vacsiny

spocitane a zratane....z piatich argumentov ktorymi si sa snazil spochybnit moje tvrdenie o potrebe hodit 80% do kosa pri navrate ku "klasickejsej" architekture....su 4ks uplne mimo a aspon jeden trosku k veci. Super.

"Okrem toho, ziadal som ta iba o jeden controller"....

na toto som uz reagoval...to tejto predstavy o CQRS ambiciu prispievat nemam....(a neviem, ako by som prispel jednym kontrollerom bez fixnutia okolitej architektury)...nerozumiem, nechapem...co a preco odomna chces....

"pretoze sa mi neche pisat RAW sql commandy, nechcem zatial byt zavysli na kontretnej DB, lahko sa to deployuje, lahko sa to mockuje v testoch a vie to bezat inmemory aj bez DB enginu."

OK, tazke nic, co by Ti chybalo pri NoSQL databaze....

a mocky v integracnych testoch? Pre mna silna kava a uplne ina tema.

"ak nemas v umysle urobit nejaky contribution, ani sa neunuvaj odpispovanim"

napisal som Ti dovody, preco nemam zaujem/motivaciu prispiet...specialne v tom stave v ako je to teraz.

sorry, ale zatial to bezi na starom engine....ktory nie je dobry...ale ak ho ma nahradit nieco, co niekto urobil ako svoj v monych smeroch nevydareny experiment a ku akejkolvek (vecnej) kritike sa stavia takto....tak som zvedavy...ako to bude vyzerat...ked bude vladnut repository, z ktoreho tento portal pobezi...(= zacinam mat pochybnosti, ci som urobil dobre, ze som sa to snazil podporit)

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
Liero
18. 9. 2018 10:23:28
Body: 9705
Najaktívnejší č.: 6

RE: Spigi

take ake argumenty som preskocil?

Ze preco relacna databaza? Ok, takze:

1. SQL + Entity framework tam uz je kvoli asp net identity providerovi a UI. Hladal som aj NoSQL alternativy, ale tam je kvalita a support neporovnatelna s default identity frameworkom a prekodovat to je zdlhava a uplne zbytocna robota.

2. Na command casti mam SQL, ale vyuzivam ju defacto ako dokumentovu databazu (JSON column). Mohol som tam dat NoSQL, ale neprinieslo by mi to absolutne nic, okrem toho, je to trivialne vymenit v buducnosti ak bude treba. Sam si v minulosti viackrat viacerym ludom otrepaval o hlavu, ze aj SQL sa da pouzit ako dokumentova databaza.

3. S query castou je to podobne. Je tam sice relacna databaza, ale je denormalizovana, navrhnuta presne podla poziadaviek views. (Vid napr ForumThread.ParticipantsCsv stlpec, kde si ukladam poslednych n prispievatelov). Co ti vlastne vadi? ze mam relaciu medzi Content tabulkou a tagmi? Ano, dalo by sa tu pouzit NoSQL, ale vzhladom na to ze tu uz mam SQL koli Identity providerovi, neviem co by som tym ziskal. Query cast mi perfektne sluzi tak ako je, mozem si ju ohybat tak ako chcem a vykon je dostatocny.

4. V case ked som to zacal pisat neexistoval .NET Standard 2.0 a NoSQL databazy vacsinou nemali .net core API. Na raw komunikaciu cez REST api som naozaj nemal chut.

5. Nemam skusenosti s NoSQL databazami, takze by som si ani nevedel vybrat

6. Nemal som cas experimentovat s NoSQL databazami. Do EF prave dorabaju providera pre CosmosDB, cakal som aj nato. (EF Core nieje iba ORM, to je iba volitelna sucast -Microsoft.EntityFrameworkCore.Relational)

7. Stale mam v plane to v buducnosti premigrovat, ale teraz by som tym iba zbytocne stracal cas.

8. Vidim sample projekty Dina Esposita (autor Microsoft .NET - Architecting Applications for the Enterprise) ako pouziva SQL databazu v query casti. Napr: https://github.com/despos/NextGen

Co som este preskocil?

[Reakcia]

photo
Liero
18. 9. 2018 10:39:30
Body: 9705
Najaktívnejší č.: 6

RE: Spigi

V skratke, cisto NoSQL riesenie by bolo pre mna prilis komplikovane a mat kombinaciu viacerych databaz tiez nechem, pokial netreba, no vdaka CQRS to nieje az taky problem urobit ak bude treba

[Reakcia]

photo
T
18. 9. 2018 16:31:26
Body: 21495
Najaktívnejší č.: 2

RE: Spigi

1. napisat si identity providera pre .net core nie je nic zdlhave ani zlozite, ale ok. Toto je argument. (len pre istotu, uz sme sa posunuli do roviny, ze ked si sa uz rozhodol pre ES, preco si zostal pri relacnej...pri uchovavani udajov releacne je jasne, ze by si robno pouzil tiez). A ono este taka vec, nikde nie je napisane, ked si sa uz rozhodol pre CQRS a ES, ze cele riesenie musi byt. Praveze je rozumne aplikovat len pre tie domeny riesenia, kde ma zmysel a je uplne bezne, ze sa komninuju pristupy pre rozne domeny aj technologie.

2. ano otrepaval a ano da sa, ak nemam lepsiu moznost a ak mam fakt dovod. ..."ale neprinieslo by mi to absolutne nic"....NoSQL by v tomto projekte neprinieslo nic v tom istom zmysel ako nepriniesol nic ES. Ak ale akceptujem, ze som pouzil event sourcing...no sql databaza urcite ma co ponuknut specialne taka, ktora je na ES sita....napr. event store (https://eventstore.org/docs/getting-started/?tabs=tabid-1%2Ctabid-dotnet-client%2Ctabid-dotnet-client-connect%2Ctabid-4(opakujem sa, ma v sebe vsetko potrebne...storage, bus, denormalizery, cep/sagy....)...a teraz spat k bodu 1....identity provider sa Ti zda zbytocne implementovat (OK) alebo celu tuto infrasturkturu implemenetovat a spajat rozne technologie nie?

Trosku ina technika/architektura pri ravendb, ktora zabezpeci to iste....https://ravendb.net/articles/cqrs-and-event-sourcing-made-easy-with-ravendb...zda sa Ti jedno alebo druhe zlozite?

3. Ako moze byt denormalizovana ked tam mas relacie? Povedzme, ze je ciastocne denormalizovana, ale fakt neviem, podla akeho pravidla. Ten paradox je taky, ze kym v command casti to ukladas denormalizovane uplne a cez ES, tu si to spatne ciastocne normalizujes. Btw. JSON sa da idexovat, preco si to neukladal ako JSON ak si potreboval hierarchiu? 

Jedine co ma napada, preco si to robil takto je nejaky linq provider a uvahy o jeho pouziti....aj ked si neviem predstavit, preco by si potreboval relacie...

4. OK, toto neviem posudit, uz sa neviem preniest spat v case, aka bola situacia, ale verim, ze nebola najlepsia. (napr. mongo provider bol urcite pred 1.5 rokom)

5. OK, to beriem, ale v podstate nech by si si vybral ktorukolvek dokumentovu, neurobil by si zle.(aj nedokumentovu, ale tam je zvacsa zlozitejsi start)...

6. OK, ale cakat na cokolvek od MS sa nevyplaca (nie v zlom, ale par sklamani)....

7. Len to je dvojsecne...ked to budes posuvat dalej narastie komplexnost a zacnes byt zavisly na specifickych features, ktore pri no sql mat nebudes (mozno)....

8. Teraz neviem, k comu sa mam vyjadrit...aj ja pouzivam pri CQRS (v niektorych pripadoch (dokonca vo vacsine) relacnu db aj na Q cast. Ale keby som sa z nejakeho dovodu rozhodol davat do MS SQL udaje aj pri ES....urcite by moj query model nebol relacny...z liniek sa neviem vysomarit...meno som uz pocul, ale nepoznam tvorbu/nazory....skus mi poslat nejaky normalny link, nech vidim co robi a na co sa odvolavas...

9. Podla mna si sa pustil aj tak do komplikacie, ktoru si uz mohol dotiahnut, to no sql by podla mna odobralo par problemov na konci dna.

 

Tomáš Zeman, MCSD.NET, MCPD

[Reakcia]

photo
Liero
19. 9. 2018 9:55:23
Body: 9705
Najaktívnejší č.: 6

RE: Spigi

1. "nikde nie je napisane, ked si sa uz rozhodol pre CQRS a ES, ze cele riesenie musi byt. Praveze je rozumne aplikovat len pre tie domeny riesenia, kde ma zmysel".
Zeby ma to uz napadlo? Ved tam mam Osobitny DbContext pre veci nesuvisiace s contentom. No napriek tomu som sa minimalne v tejto faze chcel vyhnut polygot storage, hoci by to architektura elegantne umoznila.


3. "Povedzme, ze je ciastocne denormalizovana, ale fakt neviem, podla akeho pravidla."
a) Jednoducho query model som si prisposobil tomu, aby sa mi to lahko a efektivne queryovalo. To je jeho prvorada uloha, nie? Kde je napisane ze vsetko musi byt uplne denormalizovane?

"Btw. JSON sa da idexovat, preco si to neukladal ako JSON ak si potreboval hierarchiu?"
b) Nerozumiem, preco by som mal znasilnovat SQL databazu, ked mozem jednoducho vyuzit to co mi ponuka. Unika mi nieco?

c) Hovorime napriklad o relacii ForumThread -> ForumPosts? No jednoducho v Index viewe nacitam ForumThread bez postov a v Detail viewe aj s postami. Okrem toho, ak bude v v jednom threade vela postov, bude treba spravit strankovanie. Ako by som to robil s JSON column?

d) Ano mohol by som si spravit separatne denormalizovane view pre Index a pre Detail, ale momentalne nevidim na to dovod. Ak ho uvidim, nieje to problem dorobit.
*Ja totiz vzdy zacnem tym jednoduchsim riesenim pokial sa to da lahko v pripade potreby zmenit. To je zakladny princip agilneho vyvoja, nie?

e) "Ten paradox je taky, ze kym v command casti to ukladas denormalizovane uplne a cez ES, tu si to spatne ciastocne normalizujes."
Nerozumiem. Do command casti mi nikdy neprudili normalizovane data, takze som ich ani nedernomalizoval a tym padom nemozem ani "spatne" normalizovat. Okrem toho, neviem ci ta relacia sa da nazvat normalizovanie dat. Ked tam vyhodim FK, tak uz budu denormalizovane? Ja ich jednoducho davam do formy zmysluplnej pre query model pri zachovani nejakej pragmatickosti.

[Reakcia]

photo
Liero
19. 9. 2018 10:13:02
Body: 9705
Najaktívnejší č.: 6

RE: Spigi

8. "meno som uz pocul, ale nepoznam tvorbu/nazory....skus mi poslat nejaky normalny link, nech vidim co robi a na co sa odvolavas..."
Ako sorry, ale spytaj sa Cortany, nebudem ti robit assistentku :)

[Reakcia]



Najaktívnejší užívatelia
1. 37800 b. photo vlko
2. 21495 b. photo T
3. 15965 b. photo spigi
4. 15450 b. photo Anonymous
5. 11120 b. photo dudok
6. 9705 b. photo Liero
7. 6920 b. photo siro
8. 6245 b. photo slavof
9. 5395 b. photo duracellko
10. 4665 b. photo xxxmatko