Przez ostatni rok pracowałem nad serią aplikacji opartych na frameworku Zend i koncentrowałem się na złożonej logice biznesowej, do której wszystkie aplikacje muszą mieć dostęp, nawet jeśli nie używają wszystkich (łatwiej niż mieć wiele folderów bibliotecznych dla każdego aplikacji, ponieważ wszystkie są połączone ze wspólnym centrum).
Nie wchodząc w szczegółowe informacje na temat tego, o co konkretnie chodzi w projekcie, szukam wkładu (ponieważ pracuję nad samym projektem) na temat tego, jak „pogrupowałem” mój kod. Próbowałem to wszystko rozdzielić w taki sposób, aby jak najbardziej usuwało to zależności.
Staram się utrzymywać go tak osobno, jak to logicznie mogę, więc za 12 miesięcy, kiedy mój czas się skończy, nikt inny nie będzie miał problemu z rozszerzeniem tego, co wyprodukowałem.
Przykładowa struktura:
applicationStorage\ (contains all applications and associated data)
applicationStorage\Applications\ (contains the applications themselves)
applicationStorage\Applications\external\ (application grouping folder) (contains all external customer access applications)
applicationStorage\Applications\external\site\ (main external customer access application)
applicationStorage\Applications\external\site\Modules\
applicationStorage\Applications\external\site\Config\
applicationStorage\Applications\external\site\Layouts\
applicationStorage\Applications\external\site\ZendExtended\ (contains extended Zend classes specific to this application example: ZendExtended_Controller_Action extends zend_controller_Action )
applicationStorage\Applications\external\mobile\ (mobile external customer access application different workflow limited capabilities compared to full site version)
applicationStorage\Applications\internal\ (application grouping folder) (contains all internal company applications)
applicationStorage\Applications\internal\site\ (main internal application)
applicationStorage\Applications\internal\mobile\ (mobile access has different flow and limited abilities compared to main site version)
applicationStorage\Tests\ (contains PHP unit tests)
applicationStorage\Library\
applicationStorage\Library\Service\ (contains all business logic, services and servicelocator; these are completely decoupled from Zend framework and rely on models' interfaces)
applicationStorage\Library\Zend\ (Zend framework)
applicationStorage\Library\Models\ (doesn't know services but is linked to Zend framework for DB operations; contains model interfaces and model datamappers for all business objects; examples include Iorder/IorderMapper, Iworksheet/IWorksheetMapper, Icustomer/IcustomerMapper)(Uwaga: foldery Moduły, Config, Layouty i ZendExtended są duplikowane w każdym folderze aplikacji, ale pominąłem je, ponieważ nie są wymagane dla moich celów.)
W przypadku biblioteki zawiera on cały „uniwersalny” kod. Środowisko Zend jest sercem wszystkich aplikacji, ale chciałem, aby moja logika biznesowa była niezależna od środowiska Zend. Wszystkie interfejsy modelu i mapowania nie mają żadnych publicznych odniesień do Zend_Db, ale faktycznie otaczają go prywatnie.
Mam więc nadzieję, że w przyszłości będę mógł przepisać programy mapujące i dbtables (zawierające Models_DbTable_Abstract, który rozszerza Zend_Db_Table_Abstract), aby oddzielić moją logikę biznesową od frameworka Zend, jeśli chcę przenieść moją logikę biznesową (usługi) do środowisko inne niż Zend (może jakiś inny framework PHP).
Korzystając z serviceLocator i rejestrując wymagane usługi w ramach bootstrap każdej aplikacji, mogę korzystać z różnych wersji tej samej usługi w zależności od żądania i dostępnej aplikacji.
Przykład: wszystkie zewnętrzne aplikacje będą miały zarejestrowany service_auth_External implementujący service_auth_Interface.
To samo dotyczy wewnętrznych aplikacji z Service_Auth_Internal implementującym service_auth_Interface Service_Locator :: getService ('Auth').
Obawiam się, że brakuje mi niektórych możliwych problemów z tym.
Jedno, o czym nie myślę, to plik config.ini dla wszystkich elementów zewnętrznych, a następnie osobna aplikacja config.ini przesłaniająca lub dodająca do globalnego zewnętrznego pliku config.ini.
Jeśli ktoś ma jakieś sugestie, byłbym bardzo wdzięczny.
Używałem przełączania kontekstu dla funkcji AJAX w poszczególnych aplikacjach, ale istnieje duża szansa, że zarówno zewnętrzne, jak i wewnętrzne otrzymają dla nich usługi sieciowe. Ponownie zostaną one rozdzielone ze względu na autoryzację i różne dostępne usługi.
\applicationstorage\Applications\internal\webservice
\applicationstorage\Applications\external\webservice