Spravné struktura modulů a presenterů

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
fenix
Člen | 16
+
0
-

Ahoj,
reším teď takové dilema. Jak správně udělat strukturu modulů a presenterů.

Př) Několik uživatelů aplikace. Každý uživatel může mít několik zákazníků. Každý zákazník může mít několik faktur.
Samozřejmě uživatel může editovat jen své zákazníky a jen faktury jeho zákazníků.

Teď přichází to dilema.

Dle mě je nejsprávnější struktura:

CustomerModule\XxxPresenter
Customer\Base
Customer\Default < Customer\Base - správa zákazníků
Customer\Invoice < Customer\Base - správa faktur

Ovšem při zamyšlení nad DRY je tato struktura nedostačující. Proč? Protože:

  1. seznam zákazníků dodám v pohodě, ten podvrhnout nelze
  2. editace/smazání/… – zde už musím ověřit, zda patří zákazník uživateli
  3. správa faktur – zde též musím ověřit, zda faktura patři zákazníkovy, který patří uživateli, uf

S výše uvedenou strukturou bych musel dělat zvlášť ověřování v Default:edit a zvlášť v Invoice:edit
Kdybych pak chtěl například přidat drobečkovou navigaci, tak zase porušuji DRY.

Mnohem lepší je mít:

Customer\Base
Customer\Default < Customer\Base- pouze výpis zákazníku
Customer\BaseCustomer < Customer\Base- persistentni parametr customerId, ověření, zda zákazník patří uživateli, ...
Customer\Administration < Customer\BaseCustomer - edit, delete zákazníka
Customer\Invoice < Customer\BaseCustomer - správa faktur

Perfektní, ověřování mám na jednom místě, drobečkovou navigaci taky udržuji na jednom místě, v podstatě v bezpečnosti „nemohu“ udělat chybu (nemohu někde něco zapomenout, protože ji udržuji na jednom místě).
Nelibí se mi ale struktura: Default obsahuje jen akci na výpis, ale logicky edit, delete a pod. patří sem (Presenter by měl řešit zákazníka). Vznikají mi další dva presentery BaseCustomer (jehož jméno se mi nějak nelibí) a Administration (lepší název mě nenapadl). Dále se předává persistentní parametr customerId, což u faktur v celku nevadí, i když třeba u editace faktury tento atribut nepotřebuji (faktura obsahuje customerId v databázi), ale u editace zákazníka bych raději url /customer/administration/edit/2, jenže na to bych musel udělat další routu.
Celkově se mi ta struktura zdá nepěkná.

Další řešení je mít Default pro výpis zákazníku o modul výše a nazvaný CustomerPresenter, a BaseCustomer nahradit Base, tím by se struktura „zhezčila“, ovšem nevyřešil bych customerId a CustomerPresenter už není v modulu Customer, kam rozhodně patří.

Další varianta je struktura:

Customer\Base
Customer\Default < Customer\Base- pouze výpis zákazníku
Customer\Yyy\Base < Customer\Base- persistentni parametr customerId, ověření, zda zákazník patří uživateli, ...
Customer\Yyy\Administration < Customer\Yyy\Base - edit, delete zákazníka
Customer\Yyy\Invoice < Customer\Yyy\Base - správa faktur

Struktura je opět o něco „hezčí“ Jenže takové zanoření modulu mi v tomto případě přijde zbytečné. Navíc nevím jak pojmenovat modul Yyy a stejně bych nevyřešil customerId. Příjde mi to jako kanón na vrabce a to zapisovaní linku…běs.

Pokud někoho napadá elegantní řešení, prosím podělte se.