Umístění funkce pro výpočet sazby DPH

David Matějka napsal(a):

Tohle je vec modelove vrstvy aplikace.

• base presenter neni vhodny – neni to prezentacni vec, ale business vec. muzes to chtit treba propisovat do api atd.
• staticky helpery nejsou vhodne – nejsou konfigurovatelne apod.

Ahoj,

děkuji ti za reakci.

Takže je správné použití například, že dostanu data itemů/produktů do presenteru, zpracuji do pole pro onu metodu, která je vlastně podědená z ‚hlavního‘ modelu?

V praxi myšleno asi takto:

$this->orderItems = $this->orderItemManager->getOrderItems($order->id);
// Nějaká magie ..
$calculatedPrices = $this->orderItemManager->calVat($prices);  // Chtěl bych použít i v modelu pro itemy košíku, například.

?

Šaman napsal(a):

Daň bude počítat nějaká třída (resp. funkce ve třídě). Každé místo, kde budeš chtít počítat daň si onu třídu musí injectovat a použít onu funkci.
V vše by mělo být v modelech. Presentery by měly ideálně sloužit jen jako prostředník mezi modelem a šablonami. Samy nic počitat nemají, jejich práce je zpracovat požadavek – request, načíst z modelu data a předat je správné šabloně a výsledek vrátit jako response.

Ahoj,

takže z mého příkladu je špatně to, že chci po presenteru aby oné metodě dal data, které má zpracovat když jsem je získal z totožného modelu?

Resp. chápu správně, že ten výpočet by se měl již stát v getOrderItems(), který metodu calVat() získá například od svého rodiče?

Editoval Rodney (5. 2. 2020 17:40)

CZechBoY napsal(a):

Jo, getOrderOtems by uz melo vratit ceny s dph. Pripadne si muzes udelat latte filtr na pocitani ceny s dph.

Ahoj,

určitě by to šlo řešit i filtrem, ale bohužel jelikož to chci propisovat i do emailu s informací o vytvoření objednávky, tak to musím vyřešit ještě v tý modelový části.

U většiny metod modelů se snažím docílit toho, abych jako návratový typ dostával Nette\Database\Table\Selection pro pozdější používání například při stránkování či pro využití jiných výhod.

Takže myslíš, že je v pořádku když mi getOrderItems() bude vracet například takové pole:

[
  'items' => Nette\Database\Table\Selection,  // Položky/Produkty objednávky.
  'calculated_prices' => [
    ..  // Návratová hodnota z **calVat()**.
  ],
]

Ještě třeba napadá tam uvést rovnou počet itemů, apod..

Rodney napsal(a):

U většiny metod modelů se snažím docílit toho, abych jako návratový typ dostával Nette\Database\Table\Selection pro pozdější používání například při stránkování či pro využití jiných výhod.

Můžeš si DPH spočítat na úrovni DB a mít v Selectioně obě ceny, jak bez, tak i s DPH…

Kakaku napsal(a):

Obecně se snažím nepojmenovávat třídy obecnými jmény, jako PriceManager, OrderManager atp.

Hrozně to svádí k porušení principu single-responsibility. Zaokrouhlení a počítání ceny jsou dvě různé věci. Udělal bych si třídu PriceCalculator, která by mi počítala cenu a PriceRounder, která by mi cenu zaokrouhlovala.

Nevím, co přesně má být vstup, ale ideálně něco na způsob:
PriceCalculator:countPriceByOrderItemsList(OrderItemsList $orderItemsList): int

V konstruktoru třídy PriceCalculator si přes DI předáš PriceRounder, který ti tu cenu zaokrouhlí.
No a nebo si uděláš třídu Price která to roundování bude mít přímo na sobě

Ahoj,

a je tedy správné to použít tak, jak jsem uvedl v příspěvku nad tebou?

Editoval Rodney (6. 2. 2020 14:33)