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.