Організація декількох програм Zend


10

Протягом останнього року я працював над низкою додатків, які базуються на рамках 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)

(Примітка: папки Модулі, Налаштування, Макети та ZendExtended копіюються у кожній папці додатків; але я їх опустив, оскільки вони не потрібні для моїх цілей.)

Для бібліотеки це містить весь «універсальний» код. Рамка Zend лежить в основі всіх програм, але я хотів, щоб моя бізнес-логіка була незалежною від Zend-Framework. Усі інтерфейси моделі та картографів не мають публічних посилань на Zend_Db, але насправді обертаються навколо нього приватно.

Тож я сподіваюсь, що в майбутньому я зможу переписати картографи та dbtables (містять Models_DbTable_Ab Abstract, який розширює Zend_Db_Table_Ab Abstract), щоб вивести мою ділову логіку від Zend-рамки, якщо я хочу перенести свою бізнес-логіку (послуги) на non-Zend Framework Environment (можливо, якась інша рамка 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

Відповіді:


1

Зрештою, якийсь код буде специфічним для "логіки бізнесу" вашого додатка, а деякі - "бібліотечним кодом". Наприклад, те, що перевіряє форму введення, як правило, може розглядатися як "бібліотека", тоді як те, що допомагає вам обчислити пропозиції, доступні для клієнта X в даному місяці, явно є "бізнес-логікою".

Це більше питання контролю версій, і існує багато способів, як ви зможете зняти цю конкретну кішку. Такі інструменти, як Maven (і певною мірою Phing / Ant) створені для збирання програм із різних, розрізнених джерел - на основі якогось зовнішнього файлу конфігурації (як правило, XML). Це означає, що ви можете підтримувати окремі репозиції для бібліотечного коду та імпортувати їх у додаток X, якщо вам це потрібно.

Якщо у вас є контроль над своїм хостом, ви можете подумати про переміщення речей бібліотеки в шлях включення - і підтримувати це як окремий довгостроковий проект.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.