Aplikační logiky raději méně nebo více? rubrika: Folklór

12 rmaslo
položil/-a 3.6. 2:12
 
upravil/-a 3.6. 2:19

Občas se stane, že zákazník své požadavky nespecifikuje zcela přesně a můžeme se svobodně rozhodnout zda nějakou funkčnost uděláme jako součást aplikační logiky, či zda ji uděláme jako nějakou pomocnou nápovědnou funkci UI. Příklad:

Mějme klasickou aplikaci MVC, kde zákazník vytváří třeba nějakou kalkulaci (nebo fakturu). Tato kalkulace má rozpis položek, kde se z nějakého selectu/popupu vybírá z katalogu jaká položka to je a zadává se tam cena této položky. Nicméně v katalogu položek je u každé této položky uvedena jakási "výchozí cena", kterou obchodník tvořící kalkulaci použije "nenastanou-li specifické podmínky" (které nastávají dost často)

Požadavek podle mne lze řešit dvěma způsoby:

  1. Patří to do aplikační logiky, tj. dám to do modelu. Takže zadání ceny (na formuláři) udělám nepovinné (v databázi cena je samozřejmě povinná je - tj. NOT NULL) a když ji obchodník nezadá tak tam prostě (v objektu řádek kalkulace / v triggeru) dám cenu z katalogu.

  2. Nepatří to do aplikační logiky, je to prostě jenom nějaká nápověda, která zpříjemní UI. Takže prostě, když obchodník ze selectu/popupu vybere položku z katalogu, tak rovnou vyplním (není-li vyplněna) javascriptem cenu.

Zákazníkovi je to jedno, které řešení bude zvoleno, programově jsou obě řešení triviální.

Nicméně rozdíl je v API modedu (jednou ta cena povinná je jednou ne), takže ten rozdíl určitě není úplně zanedbatelný. Rozdíl je třeba už v testování, pokud to nechám na UI, tak automatizované testy nejsou úplně triviální, kdežto v modelu to lze (aspoň podle mne) udělat snáz. Ruční testy jsou podle snadnější zase v UI, prostě na první pohled vidíme, zda se do políčka cena ta cena sepsala (a pokud nemusíme testovat vlastní save) tak je tím vlastně hotovo a není potřeba nic mockovat, či vracet db atd...
Moc neočekávám, že by se zadání během života aplikace změnilo a místo katalogové ceny se to přehodilo třeba na poslední fakturovanou cenu za toto zboží nebo za poslední fakturovanou cenu za toto zboží právě tímto obchodníkem, ale znáte to, zákazník má vždy pravdu a změní se vždy to co nečekáte...

Dali by jste to do doménové logiky nebo do UI? Kromě toho čemu byste dali přednost jako programátoři, tak klidně ohodnoťte i to čemu byste dali přednost jako uživatelé.

odkaz
17 Taco
odpověděl/-a 5.6. 19:22

View by nemělo mít žádnou logiku kromě vzhledové (takovéto - když je tento checkbox odškrtnut, tak tento box schovej). "výzhozí cena" na mě působý jako nějaký datový prvek. Je to předpokládám reálná hodnota, třeba 42. Může (ale nemusí) se vypočítávat. Tudíž zodpovědnost za to by měl nést model.

Komentáře

  • rmaslo : Nejsem si jist kde končí "vzhledová logika". Komponenty, které namapují svá data přes JS třeba i do více základních HTML prvků se běžně používají. V nejednoduším případě třeba takový ten volič s dvěma jezdcema min-max cena, který to namapuje na dva inputy. Proč by nemohla být komponenta, select/popup, která ten výběr namapuje taky do dvou polí? Podle mne to žádným pravidlům pro tvorbu View neodporuje. Případně jestli máš nějaká pravidla pro tvorbu View rád bych si je prohlédl (dej odkaz). Já se teď vlastně řídím jenom tím, že View nemá nic zapisovat do Modelu (má jen číst) a mělo by být závislé jen na stavové informaci, kterou nemá měnit (+ samozřejmě flash messages). Ale to se jeho generování na serveru, nikoliv jeho vlastního obsahu. 6.6. 0:07
  • Taco : Definoval bych to tak, že vzhledová logika je "méněcená". Neměla by přidávat žádnou podstatnou informaci. Ani hodnotu, ani roli. Příklad s tím voličem min-max: zda tam budou dvě čísla, nebo nějaké šoupátko, to je otázka view. Kolik ale bude min a kolik max to si určit nemůže. A zda to bude skákat po jednom, nebo po deseti, to záleží, zda je to faktická, nebo jen estetická informace. (Celé to ještě komplikuje skutečnost, že na webu máme defakto dvě úrovně MVC. Jednu na úrovni celé aplikace, a jednu v prohlížeči.) 6.6. 1:46

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.