Spravné struktura modulů a presenterů
- fenix
- Člen | 16
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:
- seznam zákazníků dodám v pohodě, ten podvrhnout nelze
- editace/smazání/… – zde už musím ověřit, zda patří zákazník uživateli
- 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.