Nevím, proč Vás to tak dostalo. Jde-li o reklamní plky, pak na ně nemusíte vůbec reagovat a můžete si myslet své. Nemyslím si, že ukázka kódu Vám něco řekne. To nemyslím ironicky. Jaký kus kódu byste měl namysli? A z jaké části? Dva řádky, metodu, jednu třídu, všechen kód? V první úvaze jsem se snažil poukázat na tuto problematiku. Naše řešení je takové, že spojuje všechny věci nějakým způsobem spolu dohromady (spolupracují spolu). Tzn. oddělitelnost RDB, historie, schvalovací procesy, jazykové verze a další. Vytrhnout pouze malou část pro ukázku nedává smysl. Ale zkusím uspokojit Vaši touhu po vědění :)
public void AttachnentsClear()
{
ClearCollection(DDCApplicationConstPropertyName.Attachments);
}
Nicméně, nedovolil bych si popisovat řešení, které nemám odladěné a odzkoušené. Proto se nevyjadřuji třeba k použití pro web. Mé úvahy nevedou k tomu, že si máte něco koupit. To jsem po Vás nikdy nechtěl. Máte přeci možnost si to navrhnout a naprogramovat sám. Mé úvahy vedou k tomu, že dnešní používaná. řešení, jsou nepřijatelná.
Dobrý den,
nezlobte se, ale Váš popis v podstatě říká "máme svoje fungují řešení používejte ho a jak funguje Vám neřekneme". Tento článek je o ničem, tedy vynechám-li Váš framework. Ukažte malý příklad ať ho diskutující mohou vyzkoušet. Věta "přesvědčili jsme systém, aby si myslel,že datum je aktuální" - to jistě není řešení. Apokud uspokojujete naši zvědavost dvěma metodami výše, tak si z nás asi děláte legraci. Zároveň se popíráte, neboť tvrdíte, že řešením nemáte odladěné a odzkoušené.
Prosím o jasný příklad (funkční kód, databázové schéma), ideálně stáhnutelný (Github, Bitbucket, Vaše FTP, ....)
s pozdravem Jirka
> Věta "přesvědčili jsme systém, aby si myslel,že datum je aktuální" - to jistě není řešení.
Naopak, je to řešení docela čisté ve stylu FP.
> Prosím o jasný příklad (funkční kód, databázové schéma), ideálně stáhnutelný (Github, Bitbucket, Vaše FTP, ....)
To mi nezní jako prosba ale jako dost drzej rozkaz. Bejt autorem článku, hodím na vás bobek.
Podle mě to je srozumitelné
Attachments - z toho chápu že to může být asi seznam příloh (Attachment)
ClearCollection - podle názvu to promázne nějaký obecný seznam
a proč to není clearAttachments ale ClearCollection? Protože by byla pakárna pro každou entitu takže se použije generika a udělá se metoda co funguje na všech typech kolekcí.
"krásnější" objektový zápis by ale byl DDCApplicationConstPropertyName.Attachments.Clear()
Naše řešení je takové, že spojuje všechny věci nějakým způsobem spolu dohromady (spolupracují spolu)
Jakym zpusobem?
Tzn. oddělitelnost RDB, historie, schvalovací procesy, jazykové verze a další
Jak je resena historie?
Jak jsou reseny schvalovaci procesy?
Kdyz napisete, ze to mate vyresene a nenapisete jak, je pro ctenare stejne uzitecne jako klavesa Scroll Lock.
Jaký kus kódu byste měl namysli? A z jaké části? Dva řádky, metodu, jednu třídu, všechen kód?
Je dobrym zvykem, ze pokud chcete popsat reseni nejakeho problemu, tak si vezmete jednoduchy minimalisticky priklad, ktery dany problemem trpi, ten ctenarum predstavite a pak ukazate, jak to lze vyresit lepe, napr. s vyuzitim vaseho reseni.
Nemyslím si, že ukázka kódu Vám něco řekne.
Proto se k ukazkam kodu obvykle dopisuji komentare, ktere vysvetluji, co se tam deje, viz treba clanky pana Tisnovskeho.
můžete si myslet své
Jako by se stalo.
I vzal jsem odstavec za odstavcem, kapitolu za kapitolou a hledal. Pane autore článku pomozte mi najít ...
kapitola: Měníme data
… Jsem přesvědčen, že řízení změn je dnes, na konci roku 2016, zcela nezbytnou vlastností moderních IS. … názor, z pohledu mého v pohodě.
kapitola: Reálný příklad
…. Popis reálného příkladu návrhu a jeho problem, polemika, co je nejlepším identifikátorem, ... názor, polemika, proč ne
kapitola: Konkrétní řešení
… Naše řešení vychází z předpokladu, že celý systém pracuje s dnešním (aktuálním) datem. K tomuto datu vrací aktuální záznamy. Pak šlo pouze o to, jak systém přesvědčit, že jakýkoliv dodaný datum je právě tím datem aktuálním … mohl by jste se vice rozepsat, abychom měli přesnější představu? Z celého článku se jedná o nepřesnější popis Vašeho řešení a přesto dává diskutujícím možnost takřka neomezené představivosti. Když to přeženo do extremu (za což se omlouám), Mění snad uživatel datum přes nastavení hodin? Jistě ne, zkuste popsat, o co jste musel obohatit databázové schéma
... Druhou částí bylo implementovat schvalovací a odmítací procesy nad prováděnými změnami záznamů. Čili mít plnou kontrolu nad tím, co se v DB děje. … jistě je schvalovací process důležitý, jestli Vám umožil vědět úplně všechno, co se v DB děje, … to se mi nepozdává. Možná, že jste dokázali ovlivnit chování DB až na úroveň pohybu hlaviček na disku či konkrétní práci s buňkou na SSD. V takovém případě klobouk dolů a velmi by mě zajímal postup (pomíjím-li fakt, že se nepoužila standartní komunikace s DB)
... Dále jsme požadovali, aby tato schopnost nebo vlastnost, chcete-li, byla aplikovatelná na všechny tabulky v RDB … zajimavý koncept, bohužel jste nám stále neprozradil jakým způsobem.
... Naším systémem (řešením) jsme dosáhli toho, že se nám výrazným způsobem zjednodušil vývoj. Z kódu se nám podařilo vytěsnit vše, co se odkazovalo na konkrétní RDB….. zdá se tedy, že jste to nepsal v jazyku DB, ale jedná se o něco mezi DB a aplikací. Opět bych Vás poprosil o popsání rozhraní vašeho frameworku, to, co je přínosem
kapitola: Postačující řešení
… závěr s hodnocením bez uvedení konkrétních hodnot měřených vlastností zkoumaných systémů
… Vím jen, že řešení, která se před lety nabízela, byla, z mého pohledu, nepoužitelná. Vím jen, že dnes už bez těchto nástrojů nedokážu pracovat. … prosím, jaké řešení máte namysli? Mohl by jste uvést jejich jména, reference. V čem byly nepoužitelné? Jaké vlastnosti system Vám činili obtíže. Byla by možnost připadně definovat škálu pro vlastnosti a provést vyhodnocení? Např: výkon řešení v jednotkách operací, množství redundantních dat, nutnost 1NF,2NF,3,NF ….
Příště bych rád představil další možnosti systému DDCF při nasazení ve vícejazyčném prostředí. Společná databáze, společná data, různí uživatelé, hovořící různými jazyky. … co uvidíme příště, proč ne
s přáním o dodatečné informace, které patrně měli být obsahem článku, Jiří
Nějak jste se rozepsal :)
Tak k tomu "kapitola: Konkrétní řešení".
Každý den ukládáte (do Db) nové záznamy a původní měníte (již ne tak často). Vždy ten poslední (aktuální) den vidíte všechna aktuální data tak, jak jsou tam uložena. Aplikace pracuje s aktuálním datem a časem. Existují situace, kdy budete (musíte) chtít vědět, jaký stav údajů byl ten který den. Z mnoha důvodů. Proto máme možnost přepnout aplikaci tak, aby nepracovala s datumem aktuálním, ale s datumem zadaným. K tomu datumu pak dostáváme údaje tak, jak byly tehdy uloženy. Včetně původních hodnot. Nenastavujeme systémový čas, ale čas aplikace. Aplikace má menu "Nastavit aktuální čas" a na formu je radiobutton "1. Aktuální čas" - bere aktuální systémový čas a "2. Nastavit datum" - zadáte konkrétní datum do minulosti. Podle toho, co jste nastavil, to bude použito. Takové údaje se Vám vracejí. Nevím, jestli jsem to vysvětlil pochopitelně.
Ještě k té historii. Představte si, že jste šéf a já zaměstnanec. Před půl rokem jsem měl něco udělat. Např. obeslat zákazníky. Po tom půl roce zjistíte, že některý z nich dopis nedostal a začnete mne pérovat. A já řeknu, "šéfe, vše odešlo jak mělo a to na tuto adresu, která tehdy platila". Tím se zároveň kryjeme z obou stran (zaměstnanec - zaměstnavatel).
Pak "schvalovací procesy".
Berme to s rezervou :) Nikde jsem nezmiňoval žádné hlavičky disku a pod. Ale zase příklad. Zase chci vidět (k datu v historii) kolik jsem měl zákazníků (jmenovitě) se všemi souvisejícími záznamy, jaké záznamy jsou v jakém stavu (schválené, editované, schvalované, vyřazované a pod.),
chci se podívat (v intervalu: měsíc, kvartál, ...) kolik nových záznamů vzniklo, kolik se jich vyřadilo, ...
Stačí?