지난 한 해 동안 Zend 프레임 워크를 기반으로 한 일련의 응용 프로그램을 연구 해 왔으며 모든 응용 프로그램이 모든 응용 프로그램을 사용하지 않더라도 액세스해야하는 복잡한 비즈니스 논리에 중점을 두었습니다. 그들은 모두 공통 센터와 연결되어 있기 때문에 응용 프로그램).
프로젝트가 구체적으로 무엇인지에 대해 자세히 설명하지 않고 코드를 "그룹화"한 방법에 대한 입력을 찾고 있습니다 (프로젝트 단독으로 작업하면서). 나는 가능한 한 의존성을 제거하는 방식으로 모든 것을 나누려고했습니다.
나는 논리적으로 가능한 한 분리 된 상태로 유지하려고 노력하고 있기 때문에 12 개월 만에 다른 사람이 들어 오면 내가 생산 한 것을 확장하는 데 아무런 문제가 없습니다.
구조 예 :
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)(참고 : Modules, Config, Layouts 및 ZendExtended 폴더는 각 응용 프로그램 폴더에 중복되어 있지만 목적에 필요하지 않으므로 생략했습니다.)
라이브러리의 경우 여기에는 모든 "범용"코드가 포함됩니다. Zend 프레임 워크는 모든 응용 프로그램의 핵심이지만 비즈니스 로직이 Zend 프레임 워크와 독립적이기를 원했습니다. 모든 모델 및 맵퍼 인터페이스에는 Zend_Db에 대한 공개 참조가 없지만 실제로는 비공개로 둘러 쌉니다.
그래서 나는 미래에 비즈니스 로직 (서비스)을 비 젠드 프레임 워크 환경 (다른 PHP 프레임 워크 일 수도 있음).
serviceLocator를 사용하고 각 애플리케이션의 부트 스트랩 내에 필요한 서비스를 등록하면 요청 및 액세스중인 애플리케이션에 따라 동일한 서비스의 다른 버전을 사용할 수 있습니다.
예 : 모든 외부 애플리케이션에는 service_auth_External 구현 service_auth_Interface가 등록되어 있습니다.
Service_Auth_Internal 구현 service_auth_Interface Service_Locator :: getService ( 'Auth')를 사용한 내부 응용 프로그램과 동일합니다.
나는 이것과 관련하여 가능한 몇 가지 문제가 빠져 있을지도 모른다.
반쯤 생각하는 것은 모든 외부 장치에 대한 config.ini 파일이며 전역 외부 config.ini를 재정의하거나 추가하는 별도의 응용 프로그램 config.ini입니다.
누구든지 제안 사항이 있으면 크게 감사하겠습니다.
개별 응용 프로그램 내에서 AJAX 기능에 컨텍스트 전환을 사용했지만 외부 및 내부에서 웹 서비스를 만들 가능성이 큽니다. 다시 한 번, 인증 및 사용 가능한 다른 서비스로 인해 분리됩니다.
\applicationstorage\Applications\internal\webservice
\applicationstorage\Applications\external\webservice