Specifike chovani aplikace pro jednotlive mutace na multi jazykovem webu rubrika: Návrh

Anonym
položil/-a 20.11.2014

Mame web, ktery ma 16 mutaci. V kazde mutaci je 'neco jinak'. Funkcne urcite casti proste funguji jinak. Nemyslim datove na urovni dat v DB nebo struktury v DB, ale funkcne na urovni pruchodu objednavkou (ruzne fungovani vyberu zpusoby platby, dopravy, vlastni specificke poplatky, specifika adresy v jednotlivych zemich atd), nebo treba i na urovni detailu produktu (ruzne darky a darkove akce se lisi logikou fungovani per jazykova mutace) a spouste dalsich mist po celme webu. Tam kde se vse lisi jen daty v DB neni problem. Komplikace nastava kdyz napr. v jedne mutaci se vyber zpusobu platby a dopravy a vypocet poplatku chovat zpusobem A, v dalsi mutaci zpusobem B, atd atd. Takze pak v kodu je typicky if lang = cs delej to a to, if lang = en nebo lang = de delej zase neco jineho atd atd. Za tech 7 let co to provozujeme v tom vznikl fakt slusny bordel. Tenhle postup je fakt na hodne mistech, jak uz to tak byva. Jednou to nekde nekdo pouzil a pak vsichni jen copy&paste.

Ted budeme ten system prepisovat. Zajima me, jestli existuje nejaky overeny postup nebo nejaky vzor, jak zvladat jazykove zavisle funkce na urovni navrhu aplikace tak, aby to byla dlouhodobe udrzitelna a rozsiritelna. Tj. prijde 17 mutace webu, ktera bude mit zase specificky pruchod objednavkou.

Je mi jasne ze odpovedi typu pouzit lepsi dekompozici, lepe delegovat odpovednosti trid, nebo pouzivat DI se budou jen hrnout. Me by zajimal nejaky prakticky postup/priklad.

Urcite by nekoho napadl i postup, kdy co mutace to vlastni projekt, nezavisly na ostatnich. Toto zde neni vhodne, protoze je na miste treba sklad, produktove rady, rady kategorii spravovat na jednom centralnim miste, treba v CS mutaci a vsechny ostatni mutace dane data 'jen' prekladaji do svych mutaci, ale nemohou udelat vlastni produkt, produktovou radu nebo kategorii. Takze je treba mit centralni administraci aspon pro cast systemu.

odkaz
Anonym
odpověděl/-a 20.11.2014

Tie podmienky podľa jazykovej mutácie presuň to jedinej factory, niečo ako LocaleContextFactory, potom si nakonfiguruj kontext pre každú jazykovú mutáciu tak, že keď sa vytvorí, zaregistrujú sa vždy iba potrebné event listenery. To znamená, že ostatné procesy ako objednávka, zobrazenie detailu produktu, atď. budú iba všeobecné rutiny, ktoré budú vyvolávať udalosti, na ktoré budú tie listenery počúvať. Listenery vyrieš tak aby mali iba jedinú zodpovednosť, a môžu byť tým pádom použité v rôznych jazykových mutáciách.

Komentáře

  • Anonym : Diky. Zni to jako mozne resni, ktere muze fungovat. S udalostma obecne mam takovou zkusenost, ze jakmile jich je prilis, zacina to byt trosku magie. U jedne dvou udalosti ok, ale kdyz jich budu mit desitky, ktere se navic budou retezit, muze se v tom clovek lehce ztratit. Hovorim z vlastni zkusenosti. Kod se vola jakoby nelinearne. Chapu ze vsechno ridi EventDispatcher ktery pokud je dobre napsany poskytuje i slusne ladici informace. I tak to obcas neni lehke. Ale jo dava to smysl. 20.11.2014
  • Anonym : @Vaclav Jurecek: S tým samozrejme súhlasím, treba nájsť rozumný pomer medzi tým čo má byť v tej všeobecnej rutine a čo už v listeneroch. Určite by som sa vyhol eventom typu post / pre, before / after a riešil všetko cez prioritu. Taktiež to treba aspoň trochu zadokumentovať, nech sa v tom človek neskôr nestratí. A je dobré si celý systém rozdeliť na pokiaľ možno čo najviac izolované moduly, z ktorých sa potom výsledná aplikácia poskladá. 21.11.2014

Pro zobrazení všech 6 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.